API, webhooks and access control
Where the ready-made connections do not cover the whole process, prepare deliberate access for your own integration. Also put the company's members in order, and how you react to a problem with access or data.
You extend the process with further tools while keeping sight of who has access to what. The scope of an integration is clearly defined.
Step by step
Describe the need first
Write down which data you want to read or change and in which system the result should appear. Check the Integrations available and the Data flows. Your own API use makes sense where it solves a concrete gap, rather than duplicating a connection that already works.
Open Account and API keys
Go to the API key settings. If you see access restricted, check the permissions and whether the feature is available to the company. Read the description of the scopes. Whoever builds the connection should know which operations the API genuinely offers before receiving a key.
Create a separate, named key
Click to create a key. Give it a name pointing at its use, for example "Stock report", and tick the scopes needed. For reading, do not select write permissions you do not need. Separate keys make it easier to switch off one connection later without stopping the others.
Keep the key where it belongs
After creating it, copy the key from the window and save it in your integration's secure configuration. Do not put it in a support ticket, a public repository or a screenshot. The list lets you manage keys, but does not replace how your application stores secrets.
Check one operation
With your technical colleague, make a small read following the documentation of the API available. Confirm the right company, the fields and the permission scope. Judge a write on a controlled example, with a clear expected result. Then open the changed record in the panel.
Check: The connection carries out the operation needed and the result matches the record in NavyFlame.
Add a webhook for a specific event
In the Webhooks section, choose to add one. Point at an event from the list available and the HTTPS address of your own receiver. Keep the secret you are given and pass it to whoever implements message verification. Do not save a stray address that cannot handle the event.
Check the deliveries
On the webhook, use Send test, then Delivery history. Compare the result with the receiver's log. Your own application should handle a repeat delivery of the same event correctly. Check the first real event handled by the connection as well.
Review the members and permissions
Under Account, Members, check who has access to the company. Match their roles to their duties and remove access that is no longer needed, in line with how the team is organised. Someone who packs and a technical integration need not have the same abilities as the owner.
Settle how data is restored, with support
The user panel does not offer the self-service console for creating and restoring backups described elsewhere. Under Support, settle the procedure for your service, the scope needed and who decides. The rule history lets you restore a version of a rule, but it is not a copy of the whole company.
Keep a short list of connections
Note the integration's name, its owner, the key in use, the scope and where to check for errors. Review access after a change of staff or of tooling. When switching off an unused key or webhook, confirm that the intended connection stopped and the others still work.
What this chapter gives you
You have named connections, a verified scope of access and an agreed way to proceed if data ever needs restoring.
The demo lets you learn the screens on sample data. You set up your own integrations once you have an account.
Explore the demoCreate a NavyFlame account