Dynadot API는 여러분의 시스템과 원활하게 통합되도록 설계되었습니다. 우리 API는 예측 가능한 리소스 지향 URL을 갖추고 있고, JSON으로 인코딩된 요청 본문을 지원하며, JSON 및 XML로 인코딩된 응답을 반환하고, 표준 HTTP 메서드, 인증, 응답 코드를 따릅니다.
Dynadot API는 테스트 모드와 라이브 모드 모두에서 사용할 수 있습니다. 모드는 요청을 인증하는 데 사용되는 API 키에 따라 결정됩니다. 테스트 모드에서는 실제 데이터나 트랜잭션에 영향을 주지 않고 API 통합을 시뮬레이션하고 검증할 수 있습니다.
Dynadot API는 주로 도메인 관리, 주문 처리 및 관련 서비스에 중점을 둡니다. 도메인 등록, 이전, 갱신, DNS 설정 관리, 계정 주문 조회 또는 업데이트와 같은 작업을 수행할 수 있습니다.
참고 사항: 대량 생성, 업데이트, 삭제는 지원되지 않으며, 각 요청 유형은 하나의 객체 또는 작업으로 제한됩니다.
API 요청을 시작하기 전에 API 키와 API 시크릿을 생성하는 것이 필수적입니다.
이 키들은 인증을 위해 필요하며, 우리 API와 상호작용할 때 작업의 보안을 보장합니다.
계정 설정의 API 섹션을 통해 API 키와 API 시크릿을 모두 생성할 수 있습니다.
1. Dynadot에서 계정에 로그인하세요.
2. 도구 > API로 이동하세요.
3. 이 페이지에서 API 키 및 API 시크릿을 생성하세요.
API는 리소스에 대한 작업을 수행하기 위해 표준 HTTP 메서드를 사용합니다:
| 메서드 | 설명 |
|---|---|
| GET | GET 요청: 지정된 리소스에 대한 자세한 정보를 가져옵니다 |
| POST | POST 요청: 새 리소스 생성 |
| PUT | PUT 요청: 지정된 리소스를 완전히 업데이트합니다 |
| DELETE | DELETE 요청: 지정된 리소스를 제거합니다 |
모든 API 요청의 기본 URL은 다음과 같습니다:
https://api.dynadot.com/API 요청 URL을 구성할 때는 주 버전만 포함하면 됩니다. 마이너 및 패치 업데이트는 하위 호환되도록 설계되었으며 기존 코드를 중단시키는 변경을 도입하지 않습니다. 이는 안정성을 보장하면서 구현을 수정할 필요 없이 점진적인 개선과 수정의 이점을 누릴 수 있게 해줍니다.
향후 버전이 출시되면, 일정 기간 동안 이전 버전에 대한 하위 호환성을 유지할 것입니다. 새로운 기능과 호환되지 않는 변경 사항은 메이저 버전 업데이트에서 도입됩니다.
API 요청의 헤더에는 요청에 대한 메타데이터가 포함됩니다. 이 메타데이터는 서버가 요청을 적절히 처리하는 데 필요한 필수 컨텍스트를 제공합니다. 일반적으로 사용되는 헤더는 다음과 같습니다:
요청 본문에 전송되는 데이터의 형식을 지정합니다. 서버는 이 정보를 사용하여 요청을 올바르게 구문 분석합니다. 현재 허용되는 유일한 값은 application/json입니다.
클라이언트가 기대하는 응답 형식을 서버에 알립니다.
가능한 값: application/json, application/xml
X-Request-ID 헤더는 각 API 요청을 고유하게 식별하는 데 사용되는 (선택사항) 헤더입니다. 포함되면 이 헤더는 시스템과 로그 전반에서 요청을 추적하고 연관시키는 데 도움이 되므로 API 활동을 디버그하고 모니터링하기가 더 쉬워집니다.
X-Request-ID 값은 유효한 UUID (범용 고유 식별자)여야 하며, 표준 형식: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (예를 들어, 123e4567-e89b-12d3-a456-426614174000)를 따라야 합니다.
X-Signature 헤더는 민감한 정보를 조회하거나 데이터를 업데이트하는 요청을 포함해 트랜잭션 요청에 반드시 필요한 보안 메커니즘입니다. 이는 클라이언트가 HMAC-SHA256를 사용해 요청 페이로드에 서명하도록 요구하여 API 요청의 진위성, 무결성, 부인 방지를 보장합니다.
서명을 생성하려면 다음 값이 필요합니다
1. API 키: 고유한 API 키입니다.
2. 전체 경로 및 쿼리: 쿼리 매개변수와 함께 API 엔드포인트의 전체 경로입니다.
3. X-Request-Id: 요청 ID입니다. 사용할 수 없는 경우 빈 문자열을 입력할 수 있습니다.
4. 요청 본문: 요청 본문입니다. 비어 있거나 null이면 빈 문자열을 입력할 수 있습니다.
서명할 문자열은 위에서 언급한 값들을 다음 순서로 연결한 것입니다:
apiKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
apiKey = "your_api_key"
fullPathAndQuery = "/restful/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"
stringToSign = "your_api_key\n/restful/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"stringToSign을 구성한 후, 시크릿을 키로 사용하여 HMAC-SHA256으로 서명을 계산한 다음, 결과를 Base64 인코딩하세요.
서명은 다음 단계를 사용하여 생성됩니다:
1. HMAC-SHA256 알고리즘을 사용합니다.
2. stringToSign (UTF-8)을 입력 메시지로 사용합니다.
3. 시크릿(UTF-8)을 키로 사용하세요.
4. HMAC 출력을 Base64(표준 Base64)로 인코딩합니다
생성된 서명을 요청 헤더의 X-Signature 값으로 적용하세요
import base64
import hashlib
import hmac
import uuid
def create_signature(api_key, api_secret, full_path_and_query, x_request_id, request_body=""):
string_to_sign = (
api_key + "\n" +
full_path_and_query + "\n" +
(x_request_id or "") + "\n" +
(request_body or "")
)
digest = hmac.new(
api_secret.encode("utf-8"),
string_to_sign.encode("utf-8"),
hashlib.sha256
).digest()
return base64.b64encode(digest).decode("utf-8")
api_key = "your_api_key"
api_secret = "your_secret"
full_path_and_query = "/restful/v2/accounts/info"
x_request_id = str(uuid.uuid4())
request_body = ""
x_signature = create_signature(
api_key,
api_secret,
full_path_and_query,
x_request_id,
request_body
)
print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)API 요청의 본문은 서버로 데이터를 전송하는 데 사용됩니다. 일반적으로 POST, PUT 또는 PATCH 요청에 포함됩니다 (일반적으로 GET 또는 DELETE 요청에는 포함되지 않음).
본문 데이터의 형식은 Content-Type 헤더에 의해 결정됩니다. 일반적인 형식은 다음과 같습니다:
POST 요청: POST 메서드는 서버에 새 리소스를 생성하는 데 사용됩니다. 요청 본문에는 일반적으로 리소스 세부 정보가 포함됩니다..
PUT 요청: PUT 메서드는 기존 리소스를 완전히 교체하여 업데이트하는 데 사용됩니다. 요청 본문에는 완전히 업데이트된 리소스가 포함됩니다.
DELETE 요청: DELETE 메서드는 서버에서 기존 리소스를 제거하는 데 사용됩니다. 요청 본문이 없습니다.
GET 요청: GET 메서드는 서버에서 기존 리소스를 가져오는 데 사용됩니다. 요청 본문이 없습니다
모든 API 응답은 JSON 또는 XML 형식으로 반환되며, 본문 데이터의 형식은 Accept 헤더에 의해 결정됩니다. 해당되는 경우 요청한 데이터 또는 오류 메시지를 제공합니다.
일반적으로 응답은 Code, Message, Data의 3부분으로 구성됩니다.
코드: 요청의 상태
메시지: 상태에 대한 추가 설명
데이터: 응답 본문
HTTP 상태 코드는 클라이언트의 요청 결과를 나타내기 위해 서버가 반환하는 표준화된 세 자리 숫자입니다. 이는 요청이 성공적으로 처리되었는지, 추가 조치가 필요한지, 또는 오류가 발생했는지에 대한 필수 정보를 제공합니다. 이러한 코드는 다섯 가지 범주로 나뉘며, 각 범주는 서로 다른 유형의 응답을 나타냅니다.
우리 API의 상태 코드는 널리 인정받는 표준인 HTTP/1.1 프로토콜을 따르며, 이를 통해 일관되고 안정적인 통신을 보장합니다. HTTP/1.1을 사용함으로써 지속적인 연결과 향상된 캐싱 같은 기능을 활용해 클라이언트-서버 상호작용을 최적화합니다.
웹훅은 프로세스를 자동화하고 시스템을 통합하는 강력한 도구입니다. 웹훅을 사용하면 계정이나 도메인 설정의 이벤트 또는 변경 사항에 대한 실시간 알림을 받을 수 있습니다. 웹훅을 구성하면 외부 시스템에서 작업을 트리거하거나 데이터베이스를 업데이트하거나 특정 이벤트에 따라 알림을 보낼 수 있습니다.
Dynadot API는 도메인 등록, 이전, 갱신, 만료 등 다양한 이벤트에 대한 웹훅 알림을 지원하므로 이에 대응해 적절한 조치를 취할 수 있습니다.
웹훅을 사용하려면 알림이 전송될 URL 엔드포인트를 제공해야 합니다. 계정 설정에서 웹훅 URL, 키, 시크릿을 구성할 수 있습니다. 이벤트가 발생하면 Dynadot이 관련 데이터와 함께 지정된 URL로 POST 요청을 보냅니다.
웹훅 요청의 헤더에는 요청에 대한 메타데이터가 포함됩니다. 이 메타데이터는 서버가 요청을 제대로 처리하는 데 필요한 핵심 컨텍스트를 제공합니다. 일반적으로 사용되는 헤더는 다음과 같습니다:
요청 본문에 전송되는 데이터의 형식을 지정합니다. 서버는 이 정보를 사용하여 요청을 올바르게 구문 분석합니다. 현재 허용되는 유일한 값은 application/json입니다.
X-Signature 헤더는 민감한 정보를 조회하거나 데이터를 업데이트하는 요청을 포함한 트랜잭션 요청에 대한 필수 보안 메커니즘입니다. 이는 클라이언트가 HMAC-SHA256을(를) 사용하여 요청 페이로드에 서명하도록 요구함으로써 웹훅 요청의 진위성, 무결성 및 부인 방지를 보장합니다.
서명을 생성하려면 다음 값이 필요합니다
1. 웹훅 키: 귀하의 고유한 WEBHOOK 키입니다.
2. 전체 경로 및 쿼리: 쿼리 매개변수와 함께 웹훅 엔드포인트의 전체 경로입니다.
3. X-Request-Id: 요청 ID입니다. 사용할 수 없는 경우 빈 문자열을 입력할 수 있습니다.
4. 요청 본문: 요청 본문입니다. 비어 있거나 null이면 빈 문자열을 입력할 수 있습니다.
서명할 문자열은 위에서 언급한 값들을 다음 순서로 연결한 것입니다:
webhookKey + "\n" + fullPathAndQuery + "\n" + (xRequestId or empty String) + "\n" + (requestBody or empty String)
webhookKey = "your_webhook_key"
fullPathAndQuery = "/v2/some/endpoint?param=value"
xRequestId = "unique-request-id"
requestBody = "{\"key\":\"value\"}"
stringToSign = "your_webhook_key\n/v2/some/endpoint?param=value\nunique-request-id\n{\"key\":\"value\"}"stringToSign을 구성한 후, 시크릿을 키로 사용하여 HMAC-SHA256으로 서명을 계산한 다음, 결과를 Base64 인코딩하세요.
서명은 다음 단계를 사용하여 생성됩니다:
1. HMAC-SHA256 알고리즘을 사용합니다.
2. stringToSign (UTF-8)을 입력 메시지로 사용합니다.
3. 시크릿(UTF-8)을 키로 사용하세요.
4. HMAC 출력을 Base64(표준 Base64)로 인코딩합니다
생성된 서명을 요청 헤더의 X-Signature 값으로 적용하세요
import base64
import hashlib
import hmac
import uuid
def create_signature(webhook_key, webhook_secret, full_path_and_query, x_request_id, request_body=""):
string_to_sign = (
webhook_key + "\n" +
full_path_and_query + "\n" +
(x_request_id or "") + "\n" +
(request_body or "")
)
digest = hmac.new(
webhook_secret.encode("utf-8"),
string_to_sign.encode("utf-8"),
hashlib.sha256
).digest()
return base64.b64encode(digest).decode("utf-8")
webhook_key = "your_webhook_key"
webhook_secret = "your_secret"
full_path_and_query = "/v2/some/webhook/path"
x_request_id = str(uuid.uuid4())
request_body = ""
x_signature = create_signature(
webhook_key,
webhook_secret,
full_path_and_query,
x_request_id,
request_body
)
print("X-Request-ID:", x_request_id)
print("X-Signature:", x_signature)웹훅 요청의 본문에는 알림을 트리거한 이벤트에 대한 정보가 포함됩니다. 본문 데이터의 형식은 Content-Type 헤더에 의해 결정되며, 일반적으로 application/json입니다.
요청 본문에는 다음 매개변수가 포함됩니다:
예시:
요청 본문에는 다음 매개변수가 포함됩니다:
| 파라미터 | 설명 |
|---|---|
| 이벤트 | 알림을 트리거한 이벤트 유형입니다. |
| 이벤트 ID | 알림을 트리거한 이벤트의 ID입니다. |
| 타임스탬프 | 이벤트가 발생한 타임스탬프입니다. |
| 데이터 | 이벤트와 연결된 데이터입니다. |
웹훅 요청에 대한 응답은 요청에 지정된 Content-Type 헤더에 따라 JSON 형식으로 전송됩니다.
응답 본문에는 요청이 성공적으로 처리되었는지 또는 오류가 발생했는지와 같은 요청 상태에 대한 정보가 포함됩니다.
일반적으로 응답은 1개의 부분: 상태를 포함합니다.
예시:
요청은 보안을 위해 https(보안 소켓)를 통해 전송해야 합니다. 한 번에 1개의 요청만 처리할 수 있으므로, 현재 요청이 끝날 때까지 기다린 후 다른 요청을 보내 주세요.
계정의 가격 등급에 따라 다른 스레드 수를 받게 됩니다:
| 가격 등급 | 스레드 수 | 요청 제한 |
|---|---|---|
| 정규 | 1개 스레드 | 60/분 (1/초) |
| Bulk | 5개 스레드 | 600/분 (10/초) |
| 슈퍼 벌크 | 35개 스레드 | 6000/분 (100/초) |
참고: place_auction_bid 및 get_auction_bid는 현재 위의 속도 제한에서 제외됩니다.
도메인 감정 명령의 경우, 계정의 가격 등급에 따라 허용되는 요청 수가 달라집니다:
| 가격 등급 | 요청 제한 |
|---|---|
| 정규 | 50/일 |
| Bulk | 100/일 |
| 슈퍼 벌크 | 300/일 |
Dynadot API 샌드박스 환경에서는 실제 계정이나 실제 자금에 영향을 주지 않고 API 통합을 안전하게 테스트할 수 있습니다.
1. Dynadot 계정에 로그인한 후 API 설정 페이지로 이동하세요:
2. https://www.dynadot.com/account/domain/setting/api.html
3. API 샌드박스 키와 API 샌드박스 시크릿 키를 생성하세요.
4. 생성 후 시스템이 샌드박스 키를 활성화하고 Sandbox 계정을 만들 때까지 잠시 기다려 주세요.
5. Sandbox 계정은 테스트 목적으로 지원되는 모든 통화로 10,000의 잔액이 미리 충전됩니다.
샌드박스 환경의 API 명령은 프로덕션 환경과 기능적으로 동일합니다.
유일한 차이점은 기본 URL입니다:
프로덕션 API URL: https://api.dynadot.com
샌드박스 API URL: https://api-sandbox.dynadot.com
일부 API 명령은 샌드박스 환경에서 사용할 수 없을 수 있습니다. "API 샌드박스 지원" 레이블을 확인하려면 특정 명령 설명서를 참조하세요.
샌드박스는 주로 테스트용으로 설계되었습니다. 특정 명령은 프로덕션과 다를 수 있으며, 샌드박스 가능한 모든 복잡한 시나리오를 완전히 시뮬레이션할 수 없습니다는 프로덕션 환경에서 발견됩니다.
변경 로그는 API의 각 버전에 도입된 변경 사항, 개선 사항, 버그 수정 및 새로운 기능에 대한 자세한 기록입니다. 각 업데이트의 영향을 문서화하여 사용자와 개발자에게 투명성을 제공합니다. 이는 두 가지 핵심 부분으로 구성됩니다:
이 부분은 API의 버전 관리 시스템을 강조하며, 개발자가 기능의 발전을 추적하고 호환성을 보장하는 데 도움이 됩니다. 각 API 버전은 고유한 버전 번호(예: v1.0.1, v2.2.3)로 식별되며 중요한 이정표 또는 릴리스를 나타냅니다. 버전 관리를 통해 사용자는 준비가 되었을 때 업데이트를 선택하여 최소한의 중단으로 통합을 유지할 수 있습니다.
변경 로그 기록은 각 버전에 도입된 업데이트, 버그 수정, 사용 중단 및 개선 사항에 대한 자세한 정보를 제공합니다. 엔드포인트, 매개변수, 인증 메커니즘 또는 응답 형식에 대한 특정 변경 사항을 설명합니다. 이 섹션은 개발자가 변경된 내용을 완전히 투명하게 파악하고 그에 따라 구현을 조정할 수 있도록 보장합니다. 명확하고 자세한 변경 로그를 유지함으로써 개발자가 통합을 효과적이고 자신 있게 관리하는 데 필요한 도구와 정보를 제공하는 것을 목표로 합니다.
버전 코드는 API 업데이트를 체계적으로 식별하고 관리하는 데 사용됩니다. 이들은 시맨틱 버전 관리(SemVer) 형식을 따릅니다:
버전 코드의 각 구성 요소는 특정한 목적을 가지며, 개발자가 변경의 범위와 유형을 효과적으로 전달할 수 있도록 도와줍니다.
정의: 이전 버전과의 호환성을 깨뜨릴 수 있는 중요한 변경 사항을 나타냅니다.
형식:
x.<Minor>.x정의: 하위 호환되는 기능 추가를 나타냅니다.
형식:
x.<Minor>.x정의: 하위 호환되는 버그 수정 또는 사소한 개선을 의미합니다.
형식:
x.x.<Patch>변경 로그는 소프트웨어나 API의 각 버전에 도입된 변경 사항, 개선 사항, 버그 수정 및 새로운 기능을 자세히 기록한 것입니다. 각 업데이트의 영향을 문서화하여 사용자와 개발자에게 투명성을 제공합니다.
변경 로그의 일반적인 항목에는 다음이 포함됩니다:
설명: 변경된 내용에 대한 간단한 설명입니다.
영향을 받는 구성 요소: 변경으로 영향을 받는 특정 모듈, 엔드포인트 또는 기능.
Dynadot API의 모든 변경 사항을 확인하세요.