Skip to content
NexG ConciergeDevelopers
NexG Developers
Get an API key

Changelog and versioning

What changed in the API and when, and the rules NexG follows when the API changes.

On this page

How versions work

The version is in the path (/v1/…) and in every JSON response, as meta.api_version. Within v1, NexG only makes changes that do not break a client written to these docs:

  • new endpoints, and coming-soon endpoints going live;
  • new optional query parameters;
  • new fields in a response object;
  • new values in a field that lists states, such as an order's stage;
  • clearer error messages, with the same error codes.

Anything that could break a client (removing or renaming a field, changing its type, refusing a request that works today) ships under a new version, /v2, while /v1 keeps working. It is announced here first, with the date v1 will stop.

Fixing a known issue so an endpoint does what these docs say it does counts as a fix, not a break: known issues are listed on the endpoint's page while they last, and each fix is logged here. To stay safe through every kind of change, ignore fields you do not know, treat cursors as opaque, and branch on error.code, not on messages.

How this page stays current

The reference and this changelog are built from one registry in the NexG repository, apps/api/lib/reference. Automated checks compare it with the API's route handlers and response schemas on every change, and fail if a route is added, removed or changes method without the registry and this page changing too. You can rely on the API reference listing exactly what is served.

Changes

  1. Read one order by id

    Added

    GET /v1/orders/{id} returns one of your merchant’s orders, as the same object the list returns. It needs a key with merchant_read; an id from another merchant is answered as not found.

  2. Your orders, lists, paging, search and error statuses

    Fixed

    GET /v1/orders works: every call used to fail with 500 inside the database read behind it. Pages of orders now start with the newest and follow the cursor without losing any.

    limit is accepted (1 to 100) instead of always being refused. Pages after the first no longer skip merchants or events. A cursor the endpoint did not issue is refused with 400 instead of starting again at page one.

    q may contain commas and parentheses. GET /v1/experiences lists upcoming events again: ticket_bands and suggested_blocks are lists, as the database stores them. An unknown city on experiences returns an empty list instead of every city.

    An unknown merchant answers 404 instead of 400, and server failures answer 500 instead of 400, always with the JSON error body. NexG now logs the X-Request-Id of every server error, so a quoted id can be traced.

  3. New developer documentation

    Docs

    A new home page, guides to authentication, errors, rate limits, webhooks and connecting your systems, and an endpoint reference with request samples in curl, JavaScript and Python.

    The reference and this changelog are generated from one registry that is checked against the API’s routes on every change, and they list known issues alongside each endpoint.

  4. Bank collections and the signed bank webhook

    Added

    Banks can send signed collection events to NexG, verified with an HMAC-SHA256 signature in X-Bank-Signature. Each event is recorded once, and only a verified event marks an order paid.

    Available with the NexG Sandbox Bank on test deployments. The production site waits for a real bank.

  5. Developer console sign-in checks for bots

    Changed

    Signing in to the developer console now includes a Cloudflare Turnstile check, like the rest of nexgapp.com. API keys and requests are unaffected.

  6. One rate-limit bucket per merchant or developer

    Changed

    Requests spend tokens from a single bucket shared by all of a merchant’s keys (or all of a developer’s keys without a merchant), refilled each minute. Public reads cost 1 token and merchant order reads cost 3. A 429 carries Retry-After in seconds.

    Requests without a key share one anonymous bucket of 120 tokens a minute.

    Merchant keys stop working while the merchant is paused, suspended or delisted, or while its application is waiting for approval. They work again once it may operate.

  7. Read your merchant orders

    Added

    GET /v1/orders returns the orders of the merchant your key is bound to, newest first. It needs a key with merchant_read; the key, never the request, decides the merchant.

  8. NexG API v1

    Added

    Public reads of live merchants and their catalogues, delivery zones, upcoming experiences and bookable services, all under /v1.

    The developer console at api.nexgapp.com/developers issues keys, chosen by merchant name rather than by id.