Machine-readable: manifest · index · English Markdown
Credentials and keys
01Spatial separates who is calling from which resource is targeted.
| Credential | Purpose | Location |
|---|---|---|
| API Key | Identifies the API user and its permissions. | Portal profile. |
| Map Key | Encrypted handle for one map. | Ready map card. |
| Project Key | Targets all maps in a Project. | Project information in Spatial Maps. |
| Login token | Browser session for Portal management. | Managed by Portal; never copy it into a client. |
Choose a Map or Project
- For a single-map application, send
api_key + map_key. Its scope is explicit and it is the recommended default for production. - For a multi-map application, send
api_key + project_key. The service selects a Map within that Project. - Never send both
map_keyandproject_keyin the same localization request. - The API Key must belong to a user who can access the target Map or Project.
Secure use
- Keep keys out of public Git repositories, client logs, analytics events, and support screenshots.
- Do not put keys in ordinary web URLs. Prefer a form or request body over a query string. AR launch links generated by Space Studio are controlled preview entries and must not be redistributed publicly.
- A browser or mobile app cannot fully protect a credential embedded in its code. Public applications should use a controlled backend, short-lived authorization, or an approved production entry to limit misuse.
- Use separate keys for development, test, and production. A Map Key can be resolved only by the Portal environment that created it.
Rotation and invalidation
Regenerating an API Key in the Portal profile invalidates the previous value immediately. Before rotation, inventory every dependent client and service, update their secure configuration in stages, and verify that the old key is no longer in use.
After a Map Transfer is accepted, the Map Key remains unchanged, but the API Key used to access it must belong to the new owner. Deleting a map permanently invalidates its Map Key.