Alleen serverzijde
Een productiesleutel in een web- of mobiele app is een publieke sleutel: verzonden code is leesbaar, en minificatie is geen versleuteling. Roep de API aan vanaf uw server.
Developers
Authenticatie
Hoe het koersendpoint vandaag wordt beschermd, hoe sleutels zullen worden uitgegeven, en de behandelingsregels die het klassieke resultaat vermijden: een productiesleutel in een openbare repository.
Vandaag
Het koersendpoint is open en vereist geen sleutel. De keuze is verdedigbaar: een koers leest noch schrijft persoonlijke gegevens, en een integratie moet een prijs kunnen tonen voordat een account bestaat.
Wat nog niet is geregeld
Er wordt vandaag geen snelheidslimiet toegepast op dit endpoint. We schrijven dat liever dan een quotatabel te tonen die niet wordt gehandhaafd: de dag dat de limiet bestaat, wordt hij hier gepubliceerd met zijn waarden, zijn antwoordheaders en de code die wordt geretourneerd wanneer deze wordt overschreden.
Sleutels, zodra ze zijn uitgegeven
Een sleutel draagt zijn omgeving in zijn voorvoegsel. Een testsleutel die in productie werkte, zou een ontwerpfout zijn: het maakt de echte overdracht mogelijk waarvan u dacht dat u die simuleerde.
Authorization: Bearer sk_live_9f2c4b1e8a7d3f60c5b2a1e9d8c7b6a5| Voorvoegsel | Omgeving | Wat het toestaat |
|---|---|---|
sk_test_ | Sandbox | Elke bewerking, op gesimuleerde gegevens. Geen echte geldbeweging, geen oproep naar een betaalinstelling. Railvertragingen worden gesimuleerd zodat uw tests dezelfde wachttijden kennen als in productie. |
sk_live_ | Productie | Echte bewerkingen. Orders die met deze sleutel worden aangemaakt, verplaatsen geld: hij mag uw server nooit verlaten. |
whsec_ | Beide | Webhook-ondertekeningsgeheim. Het wordt nooit gebruikt om de API aan te roepen: het verifieert alleen dat wat u ontvangt echt van ons komt. |
Behandelingsregels
Geen enkele is origineel. Ze worden allemaal regelmatig geschonden, en zo lekken sleutels.
Nooit in een URL
Als queryparameter belandt een sleutel in serverlogs, referrer-headers en browsergeschiedenis. De Authorization-header bestaat hiervoor.
Eén sleutel per integratie
Een sleutel die door drie diensten wordt gedeeld, kan niet worden ingetrokken zonder alle drie te breken. Eén sleutel per gebruik maakt intrekking pijnloos.
Onmiddellijke intrekking bij enige twijfel
Een sleutel die per ongeluk naar een repository wordt gepusht, zelfs een privérepository, zelfs daarna verwijderd, is gecompromitteerd: de geschiedenis bewaart hem en crawlers lezen openbare repositories binnen enkele minuten.
Rotatie zonder downtime
Twee sleutels die tegelijk geldig zijn, laten u roteren zonder periode van onbeschikbaarheid.
- 1.Geef een tweede sleutel uit. Beide zijn tegelijk geldig.
- 2.Implementeer de nieuwe sleutel op uw servers, één voor één.
- 3.Controleer dat de nieuwe sleutel verkeer ontvangt en de oude niet.
- 4.Trek de oude in. Intrekking is onmiddellijk, zonder respijtperiode.
Wat we nooit zullen doen
- We zullen nooit om uw sleutel vragen via e-mail, chat of telefoon. Ondersteuning heeft die niet nodig: ze werkt met het sleutel-ID, niet met het geheim.
- We tonen een geheime sleutel nooit twee keer. Hij is zichtbaar bij aanmaak, daarna alleen het ID en de laatste vier tekens.
- We sturen geen sleutels per e-mail. E-mail reist door, en wordt bewaard door, te veel partijen.