Statisch IP voor API-allowlist: een vast IPv4 dat je partners kunnen vertrouwen

Waarom vragen API's en firewalls om een statisch IP?

API's en firewalls vragen om een statisch IP omdat een bekend bronadres een eenvoudige tweede controle is bovenop een sleutel of wachtwoord. Als een sleutel uitlekt, wordt een verzoek vanaf een onbekend adres alsnog geweigerd.

Veelvoorkomende plekken die een IP-allowlist gebruiken:

• Partner- en leveranciers-API's: logistiek, voorraad, groothandelscatalogi en datafeeds.
• B2B-dashboards die alleen logins accepteren vanaf de geregistreerde adressen van een klant.
• Cloud-firewalls en security groups die SSH, een databasepoort of een beheerpaneel openstellen voor opgegeven IP's.
• Staging- en previewservers die niet openbaar mogen zijn.
• SaaS-beheerconsoles met een optionele instelling "vertrouwde IP's".

Thuis- en kantoorverbindingen veranderen vaak van adres, en cloudfuncties of CI-runners gebruiken gedeelde, wisselende reeksen. Een gehuurd IP geeft ze allemaal één stabiele uitgang.

Welke twee allowlists zijn er in het spel?

In deze opzet komen twee verschillende allowlists samen, en ze door elkaar halen is de meest voorkomende supportvraag.

Als je machines wisselende adressen hebben, sla de proxy-allowlist dan over en gebruik in plaats daarvan de gebruikersnaam en het wachtwoord. Gebruikersnaam en wachtwoord, of een IP-allowlist (tot 10 IP's).

Hoe routeer ik API-calls via het statische IP?

Routeer API-calls via het statische IP door het in te stellen als de HTTP(S)- of SOCKS5-proxy van de client die de API aanroept. De meeste HTTP-libraries, curl en veel tools lezen een proxy-instelling of de omgevingsvariabele HTTPS_PROXY. Bevestig eerst het exitadres met een publieke echo-service en roep daarna de partner-API aan. De onderstaande adressen zijn documentatievoorbeelden; je echte IP, poort en inloggegevens staan in je account.

# 1. The address the partner will see
curl -x http://USERNAME:[email protected]:8000 https://api.ipify.org

# 2. Same proxy for every tool in this shell
export HTTPS_PROXY=http://USERNAME:[email protected]:8000
curl -H "Authorization: Bearer $PARTNER_TOKEN" https://example.com/api/v1/orders

Wat gebeurt er met de allowlist als de huurperiode eindigt?

De allowlist blijft werken zolang je hetzelfde IP houdt, dus verleng vóór de einddatum. Elke huur duurt 30 dagen vanaf levering. Verleng vanuit je account vóór de einddatum; dezelfde IP's behouden na afloop van een huur is niet gegarandeerd.

Een veilige routine voor toegang via een allowlist:

1. Huur twee IP's, niet één. Geef de partner beide adressen. Als er één vervangen moet worden, blijft de andere de integratie draaien.
2. Noteer de einddatum die naast elk IP in je account staat, en verleng een paar dagen eerder.
3. Houd het wijzigingsproces van de partner bij de hand. Weet wie hun allowlist bijwerkt en hoe lang dat duurt.
4. Test na elke verlenging met de echo-call hierboven.

Als een IP niet werkt of onbruikbaar is voor een rechtmatig gebruik, schrijf naar support: we lossen het op of vervangen het door een IP in hetzelfde land, afhankelijk van voorraad. Een vervangend IP is een nieuw adres, dus het heeft een nieuwe allowlist-vermelding nodig.

Wanneer is een gehuurd proxy-IP de verkeerde keuze?

Een gehuurd proxy-IP is de verkeerde keuze wanneer de dienst die je wilt bereiken op onze geblokkeerde lijst staat of een permanent adres nodig heeft. Sites van banken, overheidsinstanties en betaalportalen zijn op elk IP geblokkeerd, dus allowlists voor bank- en betaal-API's zijn geen gebruik dat wij ondersteunen.

Overweeg ook andere opties wanneer:

• Je je eigen servers in de cloud draait: een statisch adres van je cloudprovider, gekoppeld aan je eigen NAT-gateway, houdt het verkeer binnen je eigen infrastructuur.
• Je IPv6 nodig hebt: Alleen IPv4. IPv6-proxy's worden nog niet verkocht.
• Je hetzelfde adres jarenlang nodig hebt: een huur van 30 dagen is te verlengen, maar het is geen adrestoewijzing die je bezit.