콘텐츠로 건너뛰기

데이터 객체 엔드포인트

이 엔드포인트를 사용하여 데이터 객체 유형을 나열하고, 데이터 객체 레코드를 관리하며, 객체와 사용자 간의 관계를 관리할 수 있습니다.

중요

데이터 객체는 현재 얼리 액세스 중입니다. 데이터 객체 API 키 권한이 설정 > API 키에 표시되려면 워크스페이스가 활성화되어 있어야 합니다.

유형 엔드포인트

객체 엔드포인트

객체 관계 엔드포인트

사용자 관계 엔드포인트

기본 URL 및 인증

워크스페이스 REST 엔드포인트를 사용하고 Authorization: Bearer YOUR_REST_API_KEY를 전송합니다. 이 섹션에서는 데이터 객체 엔드포인트가 호스팅되는 위치와 요청이 인증되는 방식을 설명합니다.

엔드포인트 호스트에 대해서는 Braze API 개요를 참조하세요.
모든 요청 및 응답 페이로드는 JSON입니다.
요청은 API 키를 소유한 워크스페이스로 범위가 지정됩니다.
키에 IP 허용 목록이 있는 경우, 허용 목록에 없는 IP 주소는 403을 반환합니다.

API 키 권한

이 섹션에서는 API 키를 안전하게 범위 지정할 수 있도록 각 엔드포인트를 필수 권한에 매핑합니다.

권한	엔드포인트 그룹
`data_objects.read`	유형 및 객체 읽기, 객체 관계 읽기
`data_objects.create`	객체 생성
`data_objects.update`	객체 교체 및 업데이트
`data_objects.delete`	객체 삭제
`data_objects.user_relationships.read`	사용자 관계 읽기
`data_objects.user_relationships.create`	사용자 관계 생성
`data_objects.user_relationships.update`	사용자 관계 교체 및 업데이트
`data_objects.user_relationships.delete`	사용자 관계 삭제
`data_objects.object_relationships.create`	객체 관계 생성
`data_objects.object_relationships.update`	객체 관계 교체 및 업데이트
`data_objects.object_relationships.delete`	객체 관계 삭제

참고

객체 관계 읽기에는 data_objects.read를 사용합니다. data_objects.object_relationships.read 권한은 별도로 존재하지 않습니다.

사용량 제한

이 섹션에서는 읽기 및 쓰기 트래픽에 대한 기본 요청 할당량과 응답 헤더를 설명합니다.

버킷	기본 제한
데이터 객체 읽기	분당 50건의 요청
데이터 객체 쓰기	분당 50건의 요청

모든 응답에는 X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset이 포함됩니다.

제한된 요청의 경우, Braze는 429와 id 및 message가 포함된 오류 페이로드를 반환합니다.

{
  "errors": [
    {
      "id": "rate-limit-exceeded",
      "message": "You have exceeded your limit of 50 requests per minute."
    }
  ]
}

핵심 개념

이 섹션에서는 모든 데이터 객체 엔드포인트에서 사용되는 주요 식별자를 정의합니다.

type_name: 워크스페이스 내에서 고유한 데이터 객체 유형 머신 이름입니다.
object_id: 유형 내에서 고유한 객체 식별자입니다.
braze_id: 사용자 관계 엔드포인트에서 사용되는 Braze 사용자 ID입니다.
attributes: 구성된 스키마에 대해 유효성이 검증되는 필드 이름 기반의 객체 또는 관계 데이터입니다.

관계의 작동 방식

이 섹션에서는 엔드포인트 참조 페이지를 사용하기 전에 관계 유형, 관계 엣지, 그리고 anchor 동작에 대해 설명합니다.

관계 모델 한눈에 보기

이 다이어그램을 사용하여 유형, 레코드, 관계가 어떻게 연결되는지, 그리고 이들을 연결하면 Braze에서 무엇을 할 수 있는지 확인하세요. 대시보드에서 유형을 정의한 다음, 이러한 엔드포인트를 통해 레코드와 레코드 간의 링크를 작성합니다.

%%{init: {"flowchart": {"wrappingWidth": 400}} }%%
flowchart LR
  subgraph define["Set up in the dashboard"]
    objtype["Data object types define<br/>the fields a record has"]
    reltype["Relationship types determine<br/>which links are allowed"]
  end

  subgraph write["Write with the API"]
    person["A person you<br/>send messages to"]
    record["A business record<br/>they belong to"]
    related["Another record<br/>connected to it"]
    person -- "A user relationship links<br/>a person to a record" --> record
    record -- "An object relationship links<br/>one record to another" --> related
  end

  subgraph unlock["What it unlocks"]
    segment["Segment people by the<br/>records they belong to"]
    liquid["Personalize messages with<br/>data from those records"]
  end

  define -- "decides what you<br/>are allowed to link" --> write
  write -- "makes these<br/>possible" --> unlock

유형과 엣지는 별개입니다

관계 유형은 어떤 링크가 유효한지 정의하며 대시보드에서 관리됩니다.
관계 엣지는 레코드 간의 실제 링크이며, 이러한 API 엔드포인트를 통해 생성, 업데이트, 삭제됩니다.
관계를 작성하기 전에 다음을 사용하여 유효한 rel_kind 값을 조회합니다:
- GET /data_objects/types/{type_name}/user_relationship_types
- GET /data_objects/types/{type_name}/object_relationship_types

객체 관계에 `related_type_name`이 필요한 이유

rel_kind는 모든 객체 유형 쌍에서 전역적으로 고유하지 않습니다. 예를 들어, rel_kind는 한 객체 유형 쌍에서는 subaccount이고 다른 쌍에서는 partner_account일 수 있습니다.
따라서 객체 관계 작성 시 의도한 관계 유형과 연결의 다른 쪽 객체 유형을 식별하기 위해 rel_kind와 related_type_name이 모두 필요합니다.
related_type_name이 해당 rel_kind의 관계 유형과 일치하지 않으면 요청은 400을 반환합니다.

`anchor`는 관계 방향을 제어합니다

객체 관계는 방향성이 있습니다. URL 객체는 anchor에 따라 해석됩니다.

`anchor`	URL 객체 역할	응답의 관련 객체 키
`source` (기본값)	시작 측 (나가는 엣지)	`to_data_object`
`target`	도착 측 (들어오는 엣지)	`from_data_object`

반대 앵커 관점에서 동일한 엣지를 생성해도 하나의 기본 관계를 대상으로 합니다. 동일한 엣지에 대한 두 번째 생성 호출은 409(duplicate-object-relationship)를 반환합니다.

사용자 관계의 경로 비대칭

사용자 관계 읽기와 쓰기는 의도적으로 다른 엔드포인트 경로를 사용합니다:

읽기: GET /data_objects/objects/{type_name}/{object_id}/user_relationships
쓰기: POST|PUT|PATCH|DELETE /data_objects/objects/{type_name}/{object_id}/users

관계 속성과 객체 속성은 별개입니다

관계 엔드포인트는 엣지 수준 속성을 최상위 attributes 필드에 반환합니다.
객체 속성은 to_data_object 또는 from_data_object 아래에 중첩된 상태로 유지됩니다.
PUT은 관계 attributes를 대체하고, PATCH는 관계 attributes를 병합합니다.

실제 예시

이 예시는 일반적인 계정 워크플로를 보여줍니다:

account/acct-123을 생성합니다.
account/acct-456을 하위 계정으로 생성합니다.
rel_kind: account_user를 사용하여 사용자를 acct-123에 연결합니다.
rel_kind: subaccount를 사용하여 acct-123을 acct-456에 연결합니다.

링크를 다시 조회하려면:

GET /data_objects/objects/account/acct-123/user_relationships — 연결된 사용자 조회
GET /data_objects/objects/account/acct-123/object_relationships — 나가는 객체 링크 조회
GET /data_objects/objects/account/acct-456/object_relationships?anchor=target — 들어오는 객체 링크 조회

참고

객체 관계 및 사용자 관계의 DELETE 엔드포인트는 JSON 요청 본문이 필요합니다.

페이지네이션 및 데이터 최신성

이 섹션에서는 목록 페이지네이션 동작과 쓰기 후 예상되는 데이터 가시성 타이밍을 다룹니다.

목록 엔드포인트는 limit과 offset을 지원합니다.
limit의 기본값은 100이며, 1에서 250 사이로 제한됩니다.
offset의 기본값은 0이며, 음수 값은 0으로 조정됩니다.
쓰기는 읽기 및 Liquid 개인화에 즉시 반영됩니다.
데이터 객체 기반의 Segment 멤버십은 계산된 필터가 매시간 새로고침되기 때문에 최대 1시간까지 지연될 수 있습니다.

오류 동작

이 섹션에서는 데이터 객체 엔드포인트 전반에서 사용되는 상태 및 오류 응답 패턴을 요약합니다.

404, 409, 422, 429는 id와 message가 포함된 errors 배열을 반환합니다.
400, 401, 403은 단일 error 문자열을 반환합니다.
계약 기반 422 제한은 회사마다 다릅니다.

New Stuff!