API keys let external tools authenticate to Organizely's public Business Intelligence (BI) API and pull your purchase-order data into a data warehouse, spreadsheet, or reporting stack. Keys are managed per organization under Settings → API Keys, and the BI API they unlock is strictly read-only.
Who can manage keys
Managing API keys is an admin-only area (it requires the "API keys" permission, which admins hold by default). You can grant that permission to a Manager or Worker role from Team → Roles and Permissions, or override it for a single person from the Edit User dialog. Without the permission, the API Keys page is hidden from Settings and its content is blocked.
The BI API itself is authenticated by the key, not by a user login, so a key keeps working regardless of who created it, until you revoke it.
Creating an API key
Go to Settings → API Keys.
Click Create API key.
Enter a recognizable Name (for example, "Looker BI connector") so you can tell your keys apart later.
Choose the Scopes the key is allowed to use. Today there is exactly one scope, Purchase orders (read) ( purchase_orders:read ), and it is selected for you.
Click Create key.
Copy the key from the "Copy your API key" dialog and store it somewhere safe.
The full key (it starts with orgz_) is shown only once, at creation. Organizely stores only a hash, so the plaintext value can never be retrieved again. If you close the dialog without copying it, you will need to create a new key.
Treat a key like a password. Anyone holding it can read your purchase orders. If a key might have leaked, create a replacement and revoke the old one.
Managing your keys
The API Keys table lists every key in your organization with:
Name
Key prefix (the leading characters of the key, so you can identify it without exposing the full value)
Scopes
Last used (the date the key most recently made a request, or "Never")
Created (when the key was created)
Status (Active or Revoked)
Revoking a key
Find the key in the table.
Click Revoke on that row.
Confirm in the dialog.
Revoking takes effect immediately and cannot be undone. The next request made with a revoked key is rejected. A revoked key stays in the list (shown with a struck-through name and a Revoked badge) for your records.
The Business Intelligence API
Your API keys authenticate against Organizely's read-only Business Intelligence (BI) API, which lets external tools pull your purchase-order data into a data warehouse, spreadsheet, or reporting stack.
The complete, always-current API reference lives in our canonical API documentation: authentication, available endpoints, query parameters, incremental sync, error codes, and rate limits are all documented there.
If you have questions about API keys or the BI API, contact our support team.
Update (August 2026): more data feeds and scopes
Since this guide was first written, the Business Intelligence API has grown well beyond purchase orders. The sections above still describe how keys are created and revoked, but the coverage and scope details below supersede them. Creating, listing, and revoking keys needs the API keys permission, which admins hold by default and which they can grant to other roles under Team > Roles & Permissions.
What the API now covers
Alongside purchase orders, your key can now read:
Products and variants
Inventory levels and store locations
Inventory adjustments and adjustment reasons
Suppliers
Everything stays strictly read-only.
Scopes are now chosen deliberately
Key creation offers five scope checkboxes, and none are pre-selected (previously every scope was granted by default). Pick at least one:
"Purchase orders (read)"
"Products & variants (read)"
"Inventory levels (read)"
"Inventory adjustments (read)"
"Suppliers (read)"
A key's scopes cannot be edited after it is created. To change them, create a new key with the scopes you want and revoke the old one.
Cross-referencing with Shopify
Product, variant, inventory level, and store location records now include the matching Shopify IDs for each linked store, so you can join Organizely data to your Shopify reporting. These IDs are an addition, so integrations that do not use them keep working unchanged.