Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developers.everflow.io/llms.txt

Use this file to discover all available pages before exploring further.

Building a secure integration protects your data, your partners, and your revenue. This page covers the practices every Everflow API consumer should follow.

​
API key hygiene

API keys grant full access to your portal’s data. Treat them like passwords.
DoDon’t
Store keys in environment variables or a secrets manager (e.g. AWS Secrets Manager, HashiCorp Vault, 1Password)Hard-code keys in source code
Limit each key to the minimum permissions it needsReuse a single key across all services
Rotate keys on a regular schedule (quarterly at minimum)Share keys over email, Slack, or other unencrypted channels
Revoke keys immediately if compromise is suspectedLeave unused keys active
Keys are shown only once at creation time. If you lose a key, generate a new one and revoke the old one in the Everflow UI.

​
Key scoping

Each Network API key has its own independent permissions. Create separate keys for separate concerns:
  • A reporting-only key for dashboards and BI tools.
  • A management key for systems that create or modify offers.
  • A partner-facing key with the narrowest possible access.
This limits the blast radius if any single key is compromised.

​
IP allowlisting

Restrict API access to known IP addresses by configuring the API whitelist under Control Center > Security > API Whitelist.
  • If the whitelist is empty, API calls from all IPs are accepted.
  • Once you add at least one entry, only requests from whitelisted IPs are allowed — everything else is rejected.
  • You can whitelist one or multiple IPs per API key.
Recommended setup:
  - Add your production server IPs
  - Add your CI/CD runner IPs (if applicable)
  - Add your office / VPN egress IPs for local development
Enabling the whitelist is one of the most effective ways to prevent unauthorized API access. Even if a key is leaked, it cannot be used from an IP that is not on the list.
Review the whitelist regularly and remove stale entries. When an employee leaves or infrastructure changes, update the list promptly.

​
Enforce HTTPS

All Everflow API requests must be made over HTTPS. Plain HTTP requests are rejected. This ensures credentials and data are encrypted in transit. If you are issuing server-to-server postbacks or webhook callbacks, make sure those destination URLs also use HTTPS to avoid leaking transaction data.

​
Multi-factor authentication

Enable MFA for all users who access the Everflow platform — especially those with permission to create or manage API keys. MFA is configured under Control Center > Security > Multi-Factor Authentication and supports:
  • Authenticator app (Google Authenticator, Authy, etc.) — recommended.
  • SMS verification — acceptable as a fallback.
For affiliate and advertiser portal MFA, contact your Customer Success manager.

​
Secure webhook endpoints

If you receive webhooks from Everflow, harden the receiving endpoint:
  • Use HTTPS for your webhook URL.
  • Validate the source. Restrict inbound traffic to Everflow’s IP ranges, or verify the payload against a shared secret if configured.
  • Return quickly. Respond with a 2xx status within a few seconds; process the payload asynchronously. Slow responses may be treated as failures and retried.
  • Handle duplicates. Use the event ID or transaction ID to deduplicate, since retries can deliver the same event more than once.

​
API activity monitoring

Everflow provides built-in tools to track how your API keys are being used.

​
Usage tracking per key

Each API key has a Usage column visible in the API Keys section under Control Center > Security > API Keys. This shows request volume per key, making it easy to:
  • Identify which keys are actively in use and which are stale.
  • Spot unexpected spikes in usage that could indicate abuse or a misconfigured integration.
  • Verify that a key you intend to retire is no longer receiving traffic before revoking it.

​
Admin email notifications

Everflow automatically sends email notifications to all admin users when security-relevant events occur, such as:
  • New API keys being created.
  • Unusual access patterns or login attempts.
  • New device logins to the platform.
Make sure your admin email addresses are current so these alerts reach the right people. If an alert looks suspicious, investigate immediately — check the API key usage, review the History Log, and revoke any compromised keys.

​
History Log

Under Control Center > Accounts > History Log, you can audit all modifications made through the platform. Filter by employee and timeframe, and export logs for offline analysis.

​
Building your own monitoring

For programmatic monitoring on your side, watch for these signals:
  • Repeated 401 or 403 errors — may indicate a leaked key being used from an unauthorized context.
  • Sudden changes in request volume — could mean a runaway script or unauthorized usage.
  • Requests to endpoints your integration doesn’t use — a sign that a key may be compromised.

​
Account and access management

  • Deactivate unused accounts promptly when employees leave or change roles.
  • Use the principle of least privilege. Grant each user and API key only the access it needs.
  • Audit periodically. Review active API keys, user accounts, and IP whitelists at least quarterly.
  • Separate environments. If you maintain staging and production Everflow instances, use different API keys for each and never mix them.

​
Credential storage checklist

Before going to production, verify that:
  • API keys are stored in environment variables or a secrets manager — not in code, config files committed to git, or client-side JavaScript.
  • Your .gitignore excludes .env files and any credential files.
  • No API keys appear in log output, error messages, or URLs.
  • Keys are scoped to the minimum permissions required.
  • IP allowlisting is configured for production keys.
  • MFA is enabled for all users who can create or manage API keys.
  • Webhook endpoints use HTTPS and validate inbound requests.
  • You have a documented process for rotating and revoking keys.

​
Further reading