RTBF onboarding

TOKEN=$(curl -sS -X POST "https://login.microsoftonline.com/<ENTRA_TENANT_ID>/oauth2/v2.0/token" \
  -d "grant_type=client_credentials" \
  -d "client_id=<OAUTH_CLIENT_ID>" \
  -d "client_secret=<OAUTH_CLIENT_SECRET>" \
  -d "scope=<AUDIENCE>/.default" | jq -r .access_token)

BASE="<TEST_BASE_URL>/api-op/v1/rtbf/requests"
AUTH="Authorization: Bearer $TOKEN"
DRH_CLIENT_ID="X-ClientId: <DRH_CLIENT_ID>"
JSON="Content-Type: application/json"

# Uses $AUTH from the token step above. /self-check is a sibling of /requests.
curl -sS -i "<TEST_BASE_URL>/api-op/v1/rtbf/self-check" -H "$AUTH"
# add  -H "$TENANT"  only if you are authorized for more than one tenant.
#
# EXPECT: 200, echoing the context we resolved for your call:
# {
#   "client_id":        "<the Data Readiness Hub tenant we resolved you to>",
#   "app_id":           "<your application id>",
#   "roles_satisfied":  true,
#   "origin_verified":  true,
#   "token_expires_at": "<UTC timestamp>"
# }
#
# It creates no request and no data change. When X-ClientId is omitted, client_id
# confirms which tenant we resolved you to. A 401 or 403 here means the same as it
# would on a real request (see Scenario C) and carries the same
# X-RedPoint-CorrelationId -- fix it here, before you submit anything.

ID=$(python3 -c "import uuid; print(uuid.uuid4())")

# A1. Submit an erasure request for one synthetic subject
curl -sS -i -X POST "$BASE" -H "$AUTH" -H "$DRH_CLIENT_ID" -H "$JSON" -d "{
  \"subject_request_id\": \"$ID\",
  \"subject_request_type\": \"erasure\",
  \"subject_identities\": [
    { \"identity_type\": \"email\", \"identity_value\": \"rtbf-test-001@example.com\", \"identity_format\": \"raw\" }
  ],
  \"submitted_time\": \"2026-09-08T12:00:00Z\"
}"
# EXPECT: 201 Created, a Location header ending in /rtbf/requests/$ID,
#         body: request_status "pending", received_time set,
#         expected_completion_time = submitted_time + 30 days.
#         subject_identities is NOT echoed back (by design).

# A2. Poll its status
curl -sS "$BASE/$ID" -H "$AUTH" -H "$DRH_CLIENT_ID"
# EXPECT: 200, request_status "pending"

# A3. Cancel it while still pending
curl -sS -i -X DELETE "$BASE/$ID" -H "$AUTH" -H "$DRH_CLIENT_ID"
# EXPECT: 202 Accepted, body request_status "cancelled"

# A4. Confirm the cancel persisted
curl -sS "$BASE/$ID" -H "$AUTH" -H "$DRH_CLIENT_ID"
# EXPECT: 200, request_status "cancelled"   (final — it never changes again)

# A5. Cancel again
curl -sS -i -X DELETE "$BASE/$ID" -H "$AUTH" -H "$DRH_CLIENT_ID"
# EXPECT: 409, error.message "request cannot be cancelled in status: cancelled"

ID=$(python3 -c "import uuid; print(uuid.uuid4())")
BODY="{ \"subject_request_id\": \"$ID\", \"subject_request_type\": \"erasure\",
        \"subject_identities\": [ { \"identity_type\": \"email\", \"identity_value\": \"rtbf-test-002@example.com\", \"identity_format\": \"raw\" } ],
        \"submitted_time\": \"2026-09-08T12:00:00Z\" }"

# B1. Submit
curl -sS -i -X POST "$BASE" -H "$AUTH" -H "$DRH_CLIENT_ID" -H "$JSON" -d "$BODY"
# EXPECT: 201

# B2. Re-send the IDENTICAL body (simulates a retry after a dropped response)
curl -sS -i -X POST "$BASE" -H "$AUTH" -H "$DRH_CLIENT_ID" -H "$JSON" -d "$BODY"
# EXPECT: 201 again, returning the SAME request — nothing new was created.
#         Your connector must treat this as success, not as a duplicate error.

# B3. Re-use the same id for a DIFFERENT subject
curl -sS -i -X POST "$BASE" -H "$AUTH" -H "$DRH_CLIENT_ID" -H "$JSON" -d "{
  \"subject_request_id\": \"$ID\", \"subject_request_type\": \"erasure\",
  \"subject_identities\": [ { \"identity_type\": \"email\", \"identity_value\": \"rtbf-test-999@example.com\", \"identity_format\": \"raw\" } ],
  \"submitted_time\": \"2026-09-08T12:00:00Z\" }"
# EXPECT: 400 — the id is already bound to a different request. Mint a fresh id and resubmit.

# C1. No token at all
curl -sS -i -X POST "$BASE" -H "$DRH_CLIENT_ID" -H "$JSON" -d "$BODY"
# EXPECT: 401, "Authorization: Bearer token is required"
#         (the one credential error that tells you exactly what is wrong)

# C2. A bad or expired token
curl -sS -i -X POST "$BASE" -H "Authorization: Bearer not-a-real-token" -H "$DRH_CLIENT_ID" -H "$JSON" -d "$BODY"
# EXPECT: 403, "invalid token or tenant not granted"

# C3. A tenant you are NOT authorized for
curl -sS -i -X POST "$BASE" -H "$AUTH" -H "X-ClientId: some-other-tenant" -H "$JSON" -d "$BODY"
# EXPECT: 403, the SAME message as C2 — deliberately. The service never reveals
#         which tenants or applications exist, or how close a guess was.

# C4. Malformed body (not valid JSON)
curl -sS -i -X POST "$BASE" -H "$AUTH" -H "$DRH_CLIENT_ID" -H "$JSON" -d '{ not json'
# EXPECT: 400 with the §7.6 error object

# C5. Bad subject_request_id (uppercase / not a v4 UUID)
curl -sS -i -X POST "$BASE" -H "$AUTH" -H "$DRH_CLIENT_ID" -H "$JSON" -d '{
  "subject_request_id": "NOT-A-UUID", "subject_request_type": "erasure",
  "subject_identities": [ { "identity_type": "email", "identity_value": "x@example.com" } ],
  "submitted_time": "2026-09-08T12:00:00Z" }'
# EXPECT: 400

# C6. Unknown request id
curl -sS -i "$BASE/$(python3 -c 'import uuid; print(uuid.uuid4())')" -H "$AUTH" -H "$DRH_CLIENT_ID"
# EXPECT: 404

# C7. Capture the correlation id from a failure. Do this for EVERY non-2xx.
curl -sS -i -X POST "$BASE" -H "Authorization: Bearer not-a-real-token" -H "$DRH_CLIENT_ID" -H "$JSON" -d "$BODY" \
  | grep -i '^X-RedPoint-CorrelationId:'
# EXPECT: exactly one header carrying a random UUID v4, identical to
#         error.correlation_id in the body. A different value on every call.
#
#         Record it in YOUR logs alongside the failed request. Because C2 and C3
#         are indistinguishable to you, this id is the only way Redpoint can tell
#         you which cause actually fired — and it cannot be recovered later if
#         you did not keep it.