BestDoctorsRD API

Primera llamada

Todas las rutas cuelgan de https://api.bestdoctorsrd.com y hablan JSON. Este es el aspecto de una petición:

curl -X GET "https://api.bestdoctorsrd.com/v1/partner/me" \
  -H "X-Partner-Key: {tu_clave}"

Esa clave es la vía histórica y sigue funcionando. La preferente es OAuth 2.0: se cambia el par client_id + client_secret por un token con vencimiento, y se presenta como Authorization: Bearer en las mismas rutas. Un token puede pedir menos ámbitos de los concedidos, y revocar el cliente lo invalida al instante.

curl -X POST "https://api.bestdoctorsrd.com/v1/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id={tu_client_id}&client_secret={tu_secreto}"

curl -X GET "https://api.bestdoctorsrd.com/v1/partner/me" \
  -H "Authorization: Bearer {el_access_token}"

Las dos credenciales no se mandan juntas: una petición con clave y token a la vez se rechaza, porque no hay forma correcta de elegir con cuál de las dos autorizarla.

Autenticación

Descubrimiento y rotación de claves

No hace falta copiar ninguna dirección a mano. El servidor publica un documento de descubrimiento estándar (RFC 8414) con el emisor, la dirección del endpoint de token, la del JWKS, los ámbitos que existen y las concesiones admitidas. A un cliente OAuth genérico se le da esta URL —o el emisor https://api.bestdoctorsrd.com/v1/oauth, al que él mismo le pegará el sufijo— y se configura solo:

curl -X GET "https://api.bestdoctorsrd.com/v1/oauth/.well-known/openid-configuration"

# El mismo documento, en la ruta que construyen las bibliotecas del RFC 8414:
curl -X GET "https://api.bestdoctorsrd.com/.well-known/oauth-authorization-server/v1/oauth"

Lo que ese documento no declara también informa: no hay authorization_endpoint ni flujos con navegador. La única concesión es client_credentials, porque en una integración entre sistemas no hay un usuario delante iniciando sesión.

La firma se verifica contra las claves de jwks_uri. Ese documento se puede cachear —cinco minutos— y normalmente trae una sola clave, pero durante una rotación trae dos: la saliente y la entrante. La entrante se publica antes de que se firme nada con ella, así que un cliente que refresque el JWKS dentro de ese margen nunca ve un token de una clave que no conoce, y un token firmado con la saliente sigue validando hasta que vence. Por eso hay una sola regla que cumplir del lado del integrador:

Recursos más extensos

Todos los recursos