Dinaup.DTest 10.15.0.98

Dinaup .NET SDK

Official typed client for the Dinaup platform. Talk to your tenant from .NET without dealing with raw HTTP, JSON, or auth plumbing.

What is Dinaup?

Dinaup is a multi-tenant SaaS for SMBs that consolidates billing, POS, CRM, HR, projects and more on a single configurable platform. Each tenant designs its own Sections (entities), Reports (queries) and Dynamic Documents (scripted procedures) using Dinaup Flex, and exposes them through a public API. This SDK is the typed .NET face of that API.

┌─────────────────────────────────────────────────────────────────────┐
│                                                                     │
│   Your .NET app  ──► Dinaup SDK (this repo)  ──► Dinaup tenant API  │
│                       │                                             │
│                       ├─ Sections (CRUD on per-tenant tables)       │
│                       ├─ Reports  (filtered, paginated queries)     │
│                       ├─ Files & Annotations (CDN-backed)           │
│                       ├─ Dynamic Documents (scripted procedures)    │
│                       ├─ SecureLink auth (employee login)           │
│                       └─ Postgres direct access (advanced)          │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Install

dotnet add package Dinaup

Quick start

using Dinaup;

// Connect once, reuse the client.
var client = await DinaupClientC.ConnectAsync(
    endPoint:    "https://yourtenant.dinaup.com",
    apiKey:      Guid.Parse("..."),
    apiSecret:   "...");

// Run a typed report.
var invoices = new APIVentasC();
invoices.AddFilter(VentasIngresosES.Total, ">=", 1000);
await invoices.ExecuteQueryAsync(client, page: 1, pageSize: 50);

foreach (var row in invoices.Rows)
    Console.WriteLine($"{row.NumerodefacturaCompleto}: {row.Total}");

See test/ for ~200 worked examples covering every public API.

Capabilities

• CRUD on dynamic Sections — every per-tenant entity is exposed with typed rows and relationship navigation.
• Reports & filters — typed reports with filter, between, in, date-range overlap, ordering, pagination.
• Files & Annotations — upload, dedup by SHA-1, signed URLs, public CDN gallery.
• Dynamic Documents — invoke server-side scripts that return HTML, XML, PDF, etc.
• SecureLink Auth — authenticate end-user employees against auth.dinaup.com.
• Two write modes — direct (fast, no business rules) and virtualized (runs scripts, events and computed fields).
• Postgres direct — raw read/write access for advanced scenarios.

When a call fails

An error response from the server is thrown as HttpRequestException, with the server's text as Message and its StatusCode. Two query errors have their own type, both derived from it, so an existing catch (HttpRequestException) still catches them:

try { await report.ExecuteQueryAsync(client, page: 1, pageSize: 50); }
catch (Exceptions.QueryLimitException) { /* too heavy: add a filter */ }
catch (Exceptions.QueryTimeoutException) { /* stopped by time: retry later */ }

What goes in this SDK: generic functions only

This SDK is a general-purpose client for any integration with Dinaup. It only accepts generic functions: the ones any integration would use.

• Yes: sessions, reading and writing rows, reports, files, calling a server function (ExecuteApiFunctionAsJsonAsync), and utilities for dates, text and JSON.
• No: business rules of a module (HR, time tracking, POS, Flex…), or any function whose only caller is one Dinaup app. Those live in that app's own library. For Dinaup Play that is Dinaup.Play (its PlaySesion inherits DinaupClientC).
• Exception, Flex field rules: the tables and constants that both the Server and Play read (FlexFieldRules, FlexFixedTables, FieldRenderE). The SDK is the only library both reference, so they live here once instead of being copied in each app. Only tables and constants, no calls to the server.
• When in doubt, it does not go in. Moving a function into the SDK later is easy. Removing one breaks its public API: it is marked [Obsolete] in a patch and removed in the next minor version.

Before adding a public function, search the SDK first (.claude/sdk-catalogo.md lists every extension by the type it receives) and write down who will call it. A pull request that adds a non-generic function is rejected.

Repository structure

Dinaup/
├── src/                    ← SDK source (VB.NET, .NET 10)
├── test/                   ← test suite — see test/README.md
├── .github/                ← CI, dependabot, issue & PR templates
├── Directory.Build.props   ← shared build / packaging defaults
├── CHANGELOG.md            ← Keep a Changelog
├── CONTRIBUTING.md         ← how to contribute
├── SECURITY.md             ← vulnerability disclosure
├── LICENSE                 ← MIT
└── README.md               ← you are here

Building from source

dotnet restore src/Dinaup.vbproj
dotnet build   src/Dinaup.vbproj -c Release

To run the tests, see test/README.md.

Contributing

Pull requests welcome. Read CONTRIBUTING.md for the branch flow, commit conventions, and release process. For bugs use the bug template; for features use the feature template.

Security

Report vulnerabilities privately — see SECURITY.md. Do not open public issues for security problems.

License

MIT — see LICENSE.