Who holds the keys to your integrations?

API security means making sure the connection points your systems open to each other and to outside services are used only by authorized parties, only as much as needed, and in a traceable way. We have described an API before as the door through which two pieces of software ask each other questions and get answers. Your website connects to the payment provider, your ERP to the marketplace, and your CRM to the form service through these doors.

As the number of integrations grows, so does the number of keys to these doors. In many companies, those keys sit on a developer's laptop, in an old email or in a shared file. The care taken when the door is built is rarely matched, over the years, by care about where the key is kept. The list below is meant to close that gap.

Key management

An API key is the secret a system uses to identify itself to the other side; you can think of it as a kind of password. If it is lost or falls into someone else's hands, that person can act in your name.

• Never hard-code it. The key should live not in the application code but in a separate configuration file with restricted access, or in a secrets vault. When the code is pushed to a repository, the key should not go with it.
• Use a secure sharing channel. Keys should not be passed around by email, messaging apps or screenshots.
• Separate keys per environment. The test environment and the live environment should not use the same key.
• Rotate regularly. Keys should be changed at set intervals, and especially when someone leaves the team.
• Keep an inventory. Maintain a list of which key belongs to which service, who created it and where it is used.

Permission limits: the principle of least privilege

An integration should have only as much permission as it needs to do its job. A connection that reads shipment tracking information should not be able to delete orders; a service that reads stock from the ERP should not be able to write to the ERP.

In practice, this means:

Using one shared "admin" key across all integrations is the most common and the riskiest habit. If one connection leaks, the damage should be limited to that connection's permissions.

Rate limits and abuse

A rate limit caps the number of requests a party can make within a given time. If you expose your own API to the outside world, this limit blocks both malicious attempts and a badly written integration that could otherwise lock up your system.

When you use external services, you also need to know the other side's limits. When a limit is exceeded, the service rejects requests; your integration should recognize this, wait and then retry. Otherwise, hitting the limit leads to a burst of new attempts, which in turn leads to an even longer block. We explained how the choice between periodic polling and instant notifications affects this load in our article on what a webhook is.

Logging and traceability

When something goes wrong, the first question is "what happened, when, and who did it?" That question can only be answered with properly kept logs.

• For every request, log the time, source, action taken and result.
• Never write secrets such as passwords, keys or card details to the logs. Mask personal data unless it is actually needed.
• Keep logs for a defined period, then delete them; that period is set according to KVKK (Türkiye's Personal Data Protection Law) and business needs.
• Unusual activity, such as hundreds of failed attempts with a single key at midnight, should trigger an alert.

We cover how to turn logs into alerts in our article on integration error monitoring.

The connection itself

• All API traffic should go over an encrypted connection (HTTPS).
• Incoming data from outside, such as webhook messages, should be verified before it is processed.
• Old integrations that are no longer used should be shut down and their keys revoked.
• Software libraries should be kept up to date; older versions may have known vulnerabilities.

Quick checklist

• There is a list of all API keys, each with a known owner and place of use
• No key sits in a code repository or an email
• Test and live environment keys are separate
• Every connection has only the permissions it needs
• IP restrictions are in place wherever possible
• Rate limits are defined and there is wait-and-retry behavior when a limit is hit
• Request logs are kept and contain no secrets
• Alerts are set up for unusual activity
• Rotating keys after someone leaves the team is part of the procedure

How we do it at Globya

On every connection we build, we keep keys outside the code in configuration files with restricted access, and we give each integration only the permissions it needs. When we take over your existing integrations, we first build an inventory and review it against the list above. On connections that carry personal data, KVKK compliance requirements are never left out, and there is no extra charge for them. The server and update side is handled by the same team through our hosting and maintenance service.

Frequently asked questions