# Delete Tradeline Due to Fraud

When a tradeline has been deemed verified fraud, the deleteTradeline mutation should be used to remove the tradeline from a consumer's credit report.

## About

This flow lets your organization remove a tradeline when it is determined to be fraudulent.

The deletion flow happens in two stages:

1. **Close Due to Fraud**: Bloom marks the tradeline as closed with a fraud reason right away.
2. **Final Deletion Sync**: Bloom later finalizes the deletion and sends a `tradeline.deleted` webhook after reporting has been confirmed between our systems.

This protects data consistency while still giving you an immediate fraud action.

## Authentication

Use your normal Bloom API authentication for protected user actions.

If authentication is missing or invalid, the request will be rejected.

### Headers

| Header | Value | Description |
| --- | --- | --- |
| Authorization | `Bearer <access-token>` | Authenticates your API request. Required. |
| Content-Type | `application/json` | Always `application/json`. Required. |

## GraphQL Request

Use the `deleteTradeline(input: DeleteTradelineInput!)` mutation. Pass the tradelineID in `input.tradelineId`:

GraphQL

```graphql
mutation DeleteTradelineForFraud($input: DeleteTradelineInput!) {
  deleteTradeline(input: $input) {
    tradeline {
      id
      status
      closeReason
    }
  }
}
```

Example variables:

JSON

```json
{
  "input": {
    "tradelineId": "4c4f50ae-1977-4e64-b143-c9bfc2f80501"
  }
}
```

## Response

On success, the mutation returns the updated tradeline object.

At this point, you should expect:

- `status` to be `CLOSED`
- `closeReason` to be `FRAUD`

Example response:

JSON

```json
{
  "data": {
    "deleteTradeline": {
      "tradeline": {
        "id": "4c4f50ae-1977-4e64-b143-c9bfc2f80501",
        "status": "CLOSED",
        "closeReason": "FRAUD"
      }
    }
  }
}
```

## Downstream Workflow

After the immediate response:

1. Bloom records the fraud closure and removes active attestation linkage for that tradeline.
2. Bloom runs a follow-up deletion process on a schedule.
3. Once downstream reporting confirms timing requirements, Bloom marks the tradeline as fully deleted.
4. Bloom sends a `tradeline.deleted` webhook to eligible partner organizations.

## Webhook Behavior

When final deletion is completed, Bloom sends:

- Event type: `tradeline.deleted`

Webhook delivery follows your organization's webhook configuration and eligibility settings.

## Error Reference

### Common Request Errors

| Error message | What it means | What to do |
| --- | --- | --- |
| Invalid request | The tradeline is not in a deletable state (for example, it is already closed or deleted). | Confirm the current tradeline status, then retry only if it is open. |
| Not found | The tradelineID does not exist, or it does not belong to the authenticated user. | Verify the tradelineID and ensure you are calling with the correct user context. |
| Unauthorized | Authentication is missing or invalid. | Send a valid access token and retry. |

### Operational Notes

- Deletion finalization is asynchronous. A successful mutation response means the fraud close succeeded immediately; full deletion and webhook delivery can happen later.
- You can safely monitor webhook delivery or poll tradeline status if your workflow requires confirmation of final deletion.

## Best Practices

- Treat the GraphQL response as confirmation of **Closed Due to Fraud**.
- Treat the `tradeline.deleted` webhook as confirmation of **final deletion sync**.
- Store the tradelineID in your system so you can reconcile status changes and webhook events.