> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Developers Settings
> Use Developers settings to manage entity API keys, webhooks, API usage review, REST client collections, documentation links, and SDK entry points without exposing secrets or editing API reference docs.
**Developer access can affect production data**
Only owners and admins should manage Developers settings. API keys and webhooks can read,
create, update, or send operational data depending on their mode and scopes. Treat keys,
signing secrets, downloaded environments, and request logs like security material.
This Help Center article explains how to use the Developers settings screen safely.
Endpoint shapes, request examples, schemas, SDK details, and versioned API behavior belong
in the API Docs and API Reference tabs.
## Open Developers Settings
1. Open **Settings**.
2. Choose **Entity Settings**.
3. Open the **System** group.
4. Select **Developers**.
Developers settings are scoped to the current entity. Confirm the entity selector before
creating a key, reviewing logs, or downloading environment files. The page has a Test and
Live mode toggle so admins can separate sandbox integration work from production integration
work.
If a non-admin opens the page, Arcus shows an access-restricted state instead of the
developer tabs.
**Use Test mode first**
Create and verify integration behavior in Test mode before issuing a Live key. Move to Live
only after the integration destination, webhook destination, permission scope, and monitoring process are
known.
## Understand the Developer Tabs
* **API Keys**: create entity-scoped keys, filter by mode, search, review last use, inspect scopes, rotate when supported, revoke keys that should no longer work, and hide inactive keys from the default list.
* **Webhooks**: register HTTPS destinations that receive event notifications, choose subscribed event families, pause or resume delivery, reveal or rotate the signing secret, test active endpoints, and review delivery attempts.
* **Postman**: download REST client collections and per-entity environment files for supported tools such as Postman, Bruno, and Insomnia.
* **API Logs**: review recent requests by status, date range, method, path, latency, IP address, request ID, and API key association.
* **Analytics**: review usage summaries, request trends, latency, error rate, top endpoints, and usage by key.
* **Docs**: open the published API Docs, API Reference, and concept guides in a new tab.
* **SDKs**: see available language SDK entry points, install guidance, version notes, and links to SDK documentation.
## Create an API Key Safely
An API key lets an external script, service, or integration authenticate against the current
entity. Create keys only for named jobs with a known owner, known purpose, and narrow access.
1. Open the **API Keys** tab.
2. Confirm whether you are in **Test** or **Live** mode.
3. Select **Create API key**.
4. Name the key after the job or system that will use it.
5. Choose the least access that will work: read-only, full access, or custom scopes.
6. Add elevated scopes only when the integration owner can explain why they are required.
7. Add an IP allowlist when the caller has stable outbound IP addresses.
8. Set an expiration date when the key is for a temporary migration, test, or vendor project.
9. Create the key, copy it once, and store it in a secret manager.
The create form has these boundaries:
* **Key name** is required.
* **Mode** is Test or Live.
* **Read-only access** grants read access across entity resources.
* **Full access** grants read and write access across entity resources.
* **Custom scopes** lets you choose read and write access for Orders, Products, Accounts, Inventory, Payments, and Accounting.
* **Elevated scopes** are optional and require an acknowledgement before the key can be created.
* **IP allowlist** is optional, one entry per line, and supports CIDR notation.
* **Expiration date** is optional. Leaving it blank creates a key with no scheduled expiry.
**The token cannot be recovered later**
Arcus only shows the full API token at creation time. If the token is lost, create a replacement
key, update the integration, and revoke the old key.
## Review and Revoke Keys
Review keys on a schedule. A clean key list should make it obvious which system owns each key,
whether it is Test or Live, when it expires, when it was last used, and whether the scope still
matches the job.
* **Active-only view**: focus on keys that can still authenticate.
* **Mode filter**: separate Test cleanup from Live production review.
* **Last used**: identify abandoned jobs, retired vendors, or broken integrations.
* **Scope review**: confirm keys are not broader than the current job requires.
* **Rotate key**: replace a key when an integration can be updated safely. The new token is shown once.
* **Revoke**: disable keys for retired scripts, offboarded users, leaked secrets, or replaced integrations.
* **Auto-cleanup**: revoke old smoke, debug, and external-test keys when that cleanup action is available.
## Register Webhooks Carefully
Webhooks notify an external system when Arcus events happen. Use them when another system needs
near-real-time updates, such as order changes, invoice updates, payment results, inventory
movement, fulfillment status, return status, connector state, or accounting activity.
1. Open the **Webhooks** tab.
2. Select **Create webhook**.
3. Enter the HTTPS destination URL owned by the receiving system.
4. Add a short description that names the owner and purpose.
5. Select only the event families the receiver needs.
6. Create the webhook and copy the signing secret according to the receiver's setup process.
7. Send a test event when delivery infrastructure is available.
8. Review delivery history before assuming the receiving system is working.
Arcus requires an HTTPS URL and at least one selected event before a webhook can be
created. Webhooks can be active, paused, or disabled. Test delivery is available only
when the webhook is active.
**Rotating a webhook signing secret can break receivers**
When you rotate the signing secret, the receiving system must be updated. Plan the rotation,
copy the new value immediately, update the receiver, and test delivery before closing the work.
## Use Logs and Analytics for Troubleshooting
API Logs and Analytics are operator tools for finding integration health problems. They are
not a replacement for the API Reference. Use them to answer what happened, when it happened,
which key was involved, and whether failures are isolated or widespread.
* **API Logs**: filter by status class and date range, open request detail, copy identifiers when needed, and export request history for review.
* **Analytics**: compare request count, error rate, average latency, active keys, endpoint usage, and usage by key over the selected period.
* **4xx errors**: usually indicate caller input, missing permission, expired key, revoked key, wrong mode, or wrong entity context.
* **5xx errors**: usually need escalation with the request ID, time, key name or prefix, and affected workflow.
* **High latency**: compare endpoint trend, time window, and whether the issue affects one key or all keys.
## Use Collections, Docs, and SDK Links
The Postman, Docs, and SDKs tabs help developers get to the right technical material without
making the Help Center the source of API truth.
* **Collections**: download a REST client collection for a tool your team already uses.
* **Environment files**: download per-entity environment values, then paste the API key separately from a secure source.
* **Docs links**: open API Docs, API Reference, webhooks, authentication, error handling, rate limits, idempotency, pagination, versioning, and SDK pages.
* **SDKs**: review which language SDKs are available now, which are coming soon, and where to find install or version details.
## Security Checklist
* Use one key per script, vendor, service, or integration job.
* Name keys so a future admin knows what owns them.
* Prefer Test mode until the integration is ready for production.
* Use the narrowest scope that completes the job.
* Use expirations for migrations, pilots, vendor setup, or temporary automation.
* Use IP allowlists when practical.
* Rotate or revoke keys after staff changes, vendor changes, suspected exposure, or job retirement.
* Never paste tokens, signing secrets, environment files, or private request payloads into support articles, screenshots, tickets, or chat.
## Common Blocks
* **Developers tab is missing**: confirm your role is owner or admin and the entity has API access enabled.
* **Create API key is blocked**: check your role, entity access, selected mode, and whether the requested scope is allowed for your user.
* **A key works in Test but not Live**: confirm the key was created in Live mode, the integration uses the Live base URL, and the entity is production-ready.
* **Scope cannot be selected**: choose a narrower preset or ask an owner to review permissions.
* **Webhook test cannot be sent**: confirm the endpoint is active and check whether delivery infrastructure is temporarily pending.
* **No API logs appear**: confirm requests are using the selected mode, date range, entity, and active key.
* **Analytics are empty**: make a valid request with the selected mode, then refresh after usage is recorded.
## Related Articles
Review organization access, entity setup, and personal API key safety.
Understand owner, admin, manager, staff, and custom role access before issuing developer access.
Connect first-party and third-party services that may depend on API access, webhooks, or credentials.
Investigate authentication failures, webhook failures, sync drift, and disconnected integrations.
Review administrative activity and export evidence after key, webhook, or access changes.
Understand printing, module visibility, tags, and other system-level operating controls.