![Group 2136 (1).png]](https://support.reloadly.com/hs-fs/hubfs/Group%202136%20(1).png?height=27&name=Group%202136%20(1).png){kind=small}
Security Best Practices For Customers integrating with Reloadly APIs
Security · Best Practices
The security playbook for everyone touching the Reloadly APIGuidelines for security engineers, solution architects, product managers, and anyone integrating Reloadly into their product.
Reading time
4–5 minutes
Level
Technical
Audience
Eng, Ops & Security
Applying the right security protocols when integrating any API is what keeps your account from becoming compromised or vulnerable. This guide lays out what to follow when building on Reloadly's APIs, organized into three areas: Governance (principles everyone should know), Development (for your engineering team), and Operational (for customer-facing and ops teams).
General principles that should be known and followed by everyone in your organization, not just engineering.
Consider forming an ITSM (IT Security Management) team to set security policy, assess vulnerabilities periodically, and enforce those policies.
Make IT security an integral part of your product design and integration process, not an afterthought.
Be aware of the IT security requirements imposed by any party you integrate with.
Before going live with your product and any integration (including Reloadly), review every security measure you've taken to bulletproof your software.
Enforce strong security practices on your own customers — 2FA, regular password resets, and similar measures. This has been mandatory for everyone on the Reloadly Portal since March 13, 2023.
Review the security vulnerabilities of any third-party libraries your software depends on.
Guidelines specifically for whoever is building, integrating, or maintaining the code that talks to Reloadly.
Build a strong culture around security in design and code — it needs to be baked in, not bolted on afterward.
Never check production credentials — passwords, client ID, client secret — into version control.
Restrict source code access to only the people who actually need it.
Have engineering review code with your ITSM team to certify that all mandated security policies are fully implemented.
Never store sensitive information (like passwords) in clear text in databases or files — always use strong, industry-standard encryption.
Keep developer machines and servers patched with the latest security updates for their OS.
Stay alert to social engineering and phishing attempts.
Require end-to-end encryption via the latest SSL/TLS standards from any third-party integrator.
For sales, customer success, compliance, and anyone managing the day-to-day relationship with the Developer Portal.
Create your production Developer Portal user with a dedicated company email on your company domain — not Gmail, Yahoo, or similar.
Hand production credentials only to the authorized team or person who manages your IT production systems. Never share passwords privately — not even with Reloadly. Rotate the password every 90 days or less.
Set up 2FA on your Developer Portal account, using a device that belongs to a designated, authorized person on your production team.
Keep your production client ID and client secret away from anyone unauthorized. If you suspect they've been compromised, rotate them immediately from the Developer Portal.
As a best practice, rotate your client ID and client secret every 90 days or less, even without a known incident.
Never share your Bearer Tokens with anyone. Notify Reloadly right away if you believe one has been compromised.
For server-side integrations, share your production server IPs with Reloadly so we can whitelist them — this ensures only traffic from those servers is accepted. On a public cloud like AWS or GCP, check with your provider on stable IPs, or route traffic through a proxy with a fixed IP.
For mobile SDK integrations, add 2FA on the mobile app itself (e.g. OTP) — don't rely on simple username/password authentication alone.
How often should we rotate our client ID and client secret?
Every 90 days or less as a best practice — and immediately, without waiting for the next cycle, if you suspect they've been compromised.
Can we share our Developer Portal password with Reloadly support to speed up troubleshooting?
No. Passwords should never be shared privately with anyone, including Reloadly. Use the proper credential rotation and support channels instead.
What's the difference between IP whitelisting and 2FA in the mobile SDK case?
IP whitelisting doesn't apply when API calls originate from end-user mobile devices, since their IPs constantly change. In that scenario, secure the app itself with something like OTP-based 2FA instead.
Who should actually own these guidelines inside our company?
Governance items apply company-wide, Development items belong to engineering, and Operational items belong to whoever manages your Developer Portal account day to day — ideally with an ITSM team coordinating across all three.
Need help securing your integration?
Our support team can walk through it with you.