Conventions & errors

The patterns that apply across every Yurbi endpoint — learn them once.

Requests

• Always POST. Every endpoint is an HTTP POST with Content-Type: application/json.
• Base path depends on your platform (see below).
• Auth in the body. Pass sessionToken as a field in the JSON body, not a header.
• Routing is case-insensitive (/api/login/DoLogin and /api/Login/DoLogin both work).

Platform: where Yurbi is served

Two things decide your URLs, and they move independently:

1. The API base depends on your OS (this is what the Reference toggle switches):

So DoLogin is https://your-server.com/api/login/DoLogin on Linux/Docker and https://your-server.com/yurbi/api/login/DoLogin on Windows. The API base never moves — not even with the root-web option below.

2. The frontend page paths (embed.html, sso.html, login, /sso) depend on how the web root is set up:

On Windows you can configure IIS to serve Yurbi from the root web so users reach it at https://yurbi.example.com instead of https://yurbi.example.com/yurbi. When you do, the frontend pages move to the root — but the API stays at /yurbi/api. So a root-web Windows install mixes root-level pages with a /yurbi/api API base.

Throughout these docs, examples show the Linux/Docker forms; adjust per the tables above for your install.

On the API Reference, the Linux / Docker ↔ Windows toggle switches the API base. The page-path differences apply to the embed/SSO URLs in the guides.

Responses

Most endpoints return a JSON object with an error envelope:

{ "ErrorCode": 0, "ErrorMessage": "" }

ErrorCode: 0 means success; a non-zero code (e.g. 101 for a failed login) signals an error, with detail in ErrorMessage.

Some endpoints return a plain string instead of JSON — for example the Group membership and AppShield policy calls. They reply with text like Success, User Removed Successfully., No Changes, or an error such as Permission Denied. or Invalid Session. Handle these as strings, not objects.

The read-modify-write pattern

Endpoints that start with Save replace the entire record. The correct flow is always:

1. Fetch the current record with the matching Get call.
2. Change only the fields you need.
3. Post the whole object back.

This applies to SaveContact, SaveSecurityGroup, SaveRegSrv, SaveAppSettings, SaveAuditTypes, and SaveSMTP. Each Save wraps the record in a named key — for example SaveContact uses user, SaveSecurityGroup uses group, SaveRegSrv uses regserver. For new records, many Get/New endpoints return a blank template to start from (e.g. NewContact, NewSecurityGroup).

Identifiers & types

• Create vs update. Send ID: null (or GroupId: null) to create; send an existing ID to update.
• IDs are strings. They're large numeric strings, e.g. "639046099446490166".
• Numbers stay numbers. Some settings must be sent as numbers, not strings (for example MaxRecords and SchedulerMode in instance settings).

Good to know

• Yurbi and DashboardFox are the same product with different branding; responses may show "ProductName": "DashboardFox" and "Tenant_Mode": true.
• Trying calls in the browser from the Reference page requires your server to allow cross-origin requests (CORS). If it doesn't, copy the generated cURL and run it from a terminal, where CORS doesn't apply.