---
name: spinwheel-profile
description: Guides engineers integrating Spinwheel Profile, from prerequisite user connection to debt profile request design, credit report/score option selection, disclosure requirements, and refresh/webhook strategy. Use this skill whenever the user asks about Spinwheel debt profile, liability and credit data retrieval, bureau/score configuration, or building Profile-powered onboarding and decisioning flows.
---

# Spinwheel Profile Integration

Use this skill to design and implement Profile data retrieval with production-safe assumptions.

## Outcome

Produce a response that gives:
1. Correct prerequisite flow from user connect to profile calls.
2. Practical debt profile request design for the target use case.
3. Compliance/disclosure callouts required by public docs.
4. Snapshot and refresh architecture guidance.

## Workflow

### 1) Validate prerequisites

Before Profile guidance, verify:
- User is connected and `userId` is available.
- Integration environment is clear (`sandbox` or `production`).
- Desired liability scope is known (all liabilities or specific `liabilityType` values).

If prerequisites are missing, start with a short prerequisite section and unblock sequence.

### 2) Build the debt profile request plan

Anchor guidance to:
- `POST /v1/users/{userId}/debtProfile`
- Optional `liabilityType` filtering.
- Optional `creditReport` and `creditScore` request configuration.

When applicable, mention documented constraints (for example bureau/score combinations) and steer users away from unsupported assumptions.

### 3) Explain data semantics

Always clarify:
- Debt profile is a point-in-time snapshot.
- Ongoing freshness needs refresh/subscription strategy.
- Downstream user experiences should not assume immutable balances.

### 4) Add compliance and UX requirements

Always include:
- Required end-user terms and authorization language callouts from public docs.
- Recommendation to confirm returned profile details with the consumer where applicable.
- Separation between legal requirements and implementation suggestions.

### 5) Add operational recommendations

Include:
- Webhook adoption for async events and refresh-driven workflows.
- Environment-specific host and credential handling.
- Failure-mode handling (invalid request shape, unsupported combinations, transient API failures).

## Response format

ALWAYS use this exact structure and heading text:

### Prerequisites
### Request design
### Data interpretation
### Compliance and UX checklist
### Refresh and operations plan
### Open assumptions

If the prompt asks for a checklist, keep the same headings and put checklist bullets under the most relevant section.

## Quality bar

- Keep every recommendation implementation-oriented.
- Prefer precise API language over generalized credit-domain advice.
- Stay within publicly documented behavior.