Troubleshooting

Request payload limit

The Urban API has a defined request payload limit. This means you cannot create, update, or query an infinite number of features in a single operation. The request payload limit is handled in the API in two ways:

Queries: the limit on the number of features in a query is set with the paging argument. You cannot query more then the maximum value of the limit, which is noted in the GraphQL schema information for each node.
Mutations: setting a limit on the number of features in a mutation is not possible in a GraphQL API. As a result, creating or updating too many objects at once leads to a timeout or server error.

You are most likely to run into issues when working with objects which have geometry . This is because the maximum number of features that can be created or updated in a single API call depends on the complexity of the geometry of the feature, more specifically the number of points in it.

Use batches of data when creating or updating multiple objects, such as parcels or zones. Send each batch of data in a separate API call. If you run into problems, try adding fewer than 200 features in each operation.

Caching (delay on updates)

The Urban API backend uses a caching mechanism to help with performance. You may notice the caching when you do the following:

Run a query to return some data.
Perform an update on this data.
Run the same query again to see the updated data.

Because the backend caches the data for a short period of time you could see old data when querying right after an update. This only affects update operations combined with queries, but not create or delete operations.

Specify return fields for update operations to get the updated values instead of sending a new query.

Use dark colors for code blocksCopy
mutation {
  updateProjects(
    urbanDatabaseId: "URBAN_DATABASE_ID"
    projects: [{ attributes: { GlobalID: "GLOBAL_ID", Description: "New description" } }]
  ) {
    attributes {
      Description
    }
  }
}

Cascade on deletion

The cascade flag is available in the delete<Feature> mutations. When the flag is set to true, all dependent data of the deleted object will be deleted along with the object, or have their references to this object removed where appropriate.

Failing cascade deletion

If cascading deletion fails due to network problems, it may happen that only some of the child objects have been deleted during this process. If so, try sending the mutation and removing the parent again.