Environments and base URLs

Nuntiq runs three environments. They are completely independent: separate databases, separate keys, separate customer records. A key issued on one environment is invalid on the others.

Environment	Base URL	Use it for
Production	https://api.apreceiving.com/api	Real invoices for live customers.
Test	https://test-api.apreceiving.com/api	UAT, customer-side integration testing before go-live.
Development	https://dev-api.apreceiving.com/api	Nuntiq engineering and partner-side smoke tests.

The path layout is identical across all three. Only the host changes.

Path layout

Every Supplier API endpoint lives under /api/v1/partner/...:

https://<host>/api/v1/partner/invoices                                  POST
https://<host>/api/v1/partner/account/keys                              GET, POST
https://<host>/api/v1/partner/account/keys/{key_id}                     DELETE
https://<host>/api/v1/partner/account/keys/{key_id}/rotate              POST
https://<host>/api/v1/partner/supplier-access/request                   POST
https://<host>/api/v1/partner/supplier-access/request-code              POST
https://<host>/api/v1/partner/supplier-access/validate                  POST
https://<host>/api/v1/partner/supplier-access/mint                      POST
https://<host>/api/v1/partner/supplier-access/email-preferences         GET, POST

The /api segment is the deployed app prefix (Express BASE_API_FOLDER) and is required. /v1 is the API version; future revisions appear under /v2/... alongside it.

Which environment do I use?

Whichever the customer issuing your key chose. The key issuance flow (magic link + 6-digit code) is run by the customer's admin on a specific environment, and the key it mints only works there. You can tell which environment a key belongs to by which host minted it, not by inspecting the key itself; sk_ keys look identical across environments by design.

If you need keys on multiple environments (typical for development), the customer admin has to run the issuance flow on each environment separately. You will end up with three different (api_key, rotation_secret) pairs and three different regenerate_url values.

Related but separate hosts

Two related surfaces sit on different DNS:

• Supplier portal (https://<customer-url-name>.apquery.com) is where your contacts go to claim keys, rotate them through the UI, and manage email preferences. This is a browser-facing site, not an API. In dev it is https://<customer-url-name>.dev.apquery.com.
• Receiving inboxes (<inbox>@<customer>.apreceiving.com) are the email addresses you put in the receiving_inbox field of an invoice payload. They look like API hosts but are not; they are the email addresses where invoices can also arrive by email.

Both of these are managed by the customer in their admin portal. You do not configure them on your side.

Testing your connection

The customer-API instance answers a health check at /api/v1/ping:

curl https://api.apreceiving.com/api/v1/ping
curl https://test-api.apreceiving.com/api/v1/ping
curl https://dev-api.apreceiving.com/api/v1/ping

Each returns:

{ "message": "PONG!" }

This endpoint does not require authentication. Use it for liveness checks from your monitoring, but do not poll it tightly. The global rate limit is 300 requests per minute per source IP, shared across all routes.