Skip to main content
This page describes the rules that all Connect API content routes share. The pages for Service Locations, Fleets, Vehicles, Services and Documents link here instead of repeating them.
The Connect API is a different service from GNet core. It does not use the core.grdd.net host. The older core routes (/api/content/{griddid}) and the /api/partner/posts routes are not interchangeable with the routes in this section. See Content API overview.

Base URL

The public base URL of the Connect API is not published in these docs. Ask GRiDD support (support@grdd.net) for the Connect API base URL for your environment. The examples in this section use a shell variable:
Paths in these docs are the route paths of the Connect API service. They have no version segment.

Authentication

Send a core-issued access token on every request:
To get a token, see Get Token. The Connect API does not read the token itself. It calls core GET /api/token with the token in the token header and waits up to 5 seconds for the answer. The token must carry a company identifier (aud or griddid) and a username. A missing token, an invalid token and an expired token all return the same problem code. Request a new token and try again.

Company scope

An owner route acts on the company in your token. It does not accept a company identifier in the path, the query or the body. If you send a griddid field in a write body, the request fails with 400 invalid_request, because write bodies reject unknown keys. A record that belongs to another company is not returned to you. Reads of another company’s published content use separate public/{griddid} routes. Each type page lists them.

Roles and subscription

The owner routes in the Fleet, Vehicle, Service Location and Document pages do not check a role in the token. Creating a record can fail on a subscription check. Each type page states what applies. The Service routes are the exception. Service writes need the role ADMIN, MANAGER or VENDOR. A token with the role gateway is classed as a service credential. Some routes outside this section refuse it. The routes documented here do not check for it.
Some routes use a Service authorization header, or need an administrator role. They are for GRiDD’s own systems, such as the public website renderer. They are not part of the external API. The type pages list them only to say that they are not for external use.

Request rules

  • Send Content-Type: application/json on JSON bodies. Other media types return 415 unsupported_media_type.
  • The body limit is 1 MiB. A larger body returns 413 payload_too_large.
  • An empty body or a body that is not valid JSON returns 400 invalid_json.
  • Bodies and query strings are strict. An unknown key, a repeated query parameter or a wrong type returns 400 invalid_request. The problem body has a fieldErrors object that names each field.
  • locale and force are query parameters on most reads. locale is one of en, es, de, fr. force=true reads from the authoritative store instead of the cache.

Content languages

Fleet, Service Location, Service and Document records can hold more than one language version. If a language intent cannot be applied, the API returns 409 conflict with one of these reason values: content_language_version_missing, content_language_version_exists, content_language_final_version, content_language_record_exists. Vehicles use locale only.

Idempotency

Create requests need an Idempotency-Key header. Many update requests need it too. Each type page lists which requests need it.
  • The value is 8 to 128 printable ASCII characters, without spaces. A UUID works well.
  • If the header is required and missing, the API returns 428 idempotency_key_required. If the value is not valid, it returns 400 invalid_request.
  • The API stores the key together with your company, the operation and a hash of the request. The record is kept for 24 hours.
  • Same key, same request: the API returns the stored result and does not write again.
  • Same key, different request: the API returns 409 idempotency_conflict.
  • Same key while the first request is still running: Fleet, Vehicle, Service Location and Document requests return 202 partial_success with an operationId. Service requests return 409 idempotency_conflict.
Use a new key for each new change. Reuse a key only to retry the same request.

Version checks

Single-record reads, creates and updates return an ETag header with the record version:
Update and delete requests send that version back in If-Match:
On 412, read the record again, apply your change to the new data, and send the update with the new version. The API does not change the record when the version is stale. POST create requests do not use If-Match.

Pending operations

A write can succeed but leave follow-up work unfinished. The follow-up work includes cache refresh, linked records and projections. The API does not report this as a failure. It records an operation and returns 202.

Pending response body

A 202 write response has status: "pending", an operationId and an effects list. This delete example is from the Fleet fixture fleet-delete-pending.json:
Each effect has a name, a status (completed, pending or failed) and a retryable flag. A failed effect can also have a problemCode. For a pending create or update, the same 202 response also has the record in data.

Resume a pending operation

Send POST to the operations route of the same content type. The request has no body:
The route retries only the effects that are not complete. It returns:
  • 200 when the operation is completed.
  • 202 when it is still pending. Wait, then call it again.
  • 404 not_found when the operation does not exist or belongs to another company.
The response body has operationId, status and effects. There is no GET route for operations.
Services use the status values completed, pending and partial. A Service operation that has not committed its main write returns 409 conflict when you try to resume it.

Errors

Error responses use the media type application/problem+json. Every response, including a success, carries an X-Correlation-Id header. If you send a valid UUID in X-Correlation-Id, the API returns it. Otherwise the API creates one. Include this value when you contact support.
Each type page lists the codes that its routes actually return.

Lists

List responses return items. Most also return a meta object:
meta.partial is true when the API skipped stored rows that did not match the contract, or when it could not read every page. In that case the response also has the header X-Content-Partial: true. meta.rejected lists up to 50 skipped rows with their id and the invalid paths.

Image URLs

Image fields accept URLs only. An uploaded file is not a request field.
  • A URL under https://asset.grdd.dev/ or https://devasset.grdd.dev/ must use https, have no query string, fragment or credentials, and must not contain the path segments external, provider, providers, sign, signed, signature, upload or uploads, or a /cdn-cgi/image/ path.
  • A URL on another host must be an https URL with a real host name (it needs a dot and a top-level domain). The API keeps it as sent.
  • A gallery list must not contain duplicates, and must not repeat the primary image.
  • Fleet and Vehicle writes also check that the URL belongs to your company. See the Fleets and Vehicles pages.
An invalid image URL returns 400 invalid_request. Image objects, media IDs and fields such as photo or imageUrl in Fleet and Vehicle records are not part of the contract.

Visibility

The visibility field is one of private, partners, gnet, unlisted or public. On create, an omitted value becomes public for Fleets, Service Locations and Services. Documents get a default from their documentType. An unknown document type defaults to private.