Um cartão de crédito é uma conta com type=CREDIT e subtype=CREDIT_CARD. Os limites, o status e as datas de fechamento/vencimento vivem em creditData; as faturas vivem no recurso Bill; e as compras (inclusive parcelamentos) chegam como transações com creditCardMetadata.
Todos os endpoints exigem o header X-API-KEY e respondem em https://api.malvo.io. As transações de cartão são normalizadas: a convenção de sinal de amount é diferente da de contas bancárias — veja Convenção de sinal.

A conta de cartão (type=CREDIT)

Liste as contas do Item e filtre por type=CREDIT para encontrar os cartões.
Cada cartão traz o objeto creditData:
Account (type=CREDIT)
Em cartão, balance é o valor da fatura atualmente aberta (não é dinheiro disponível). A posição total de crédito é creditLimit = availableCreditLimit + balance + dívida não paga anterior. O number vem mascarado nos últimos 4 dígitos (ex.: "xxxx8670").
Campos relevantes de creditData:

Faturas (GET /bills)

Liste as faturas de um cartão passando o accountId (obrigatório, e precisa ser uma conta CREDIT_CARD):
Bill
No additionalInfo dos encargos: o campo é livre, mas obrigatório quando type = OTHER. Em GET /bills/{id} (retrieve), o objeto também traz accountId e cada encargo carrega o creditCardBillId da fatura-pai.

Conferindo o fechamento (settlement check)

Uma fatura N está quitada quando os encargos e pagamentos da fatura seguinte (N+1) fecham a conta:
Em pseudo-código:

Disponibilidade

Em produção (Open Finance), faturas estão disponíveis para todas as instituições reguladas.

Parcelamentos via creditCardMetadata

O Open Finance não fornece um id único agrupando todas as parcelas de uma mesma compra. Cada parcela aparece como uma transação com o objeto creditCardMetadata, que carrega o número da parcela, o total de parcelas, o valor cheio e — quando a fatura fecha — o billId.
Transação parcelada

Ciclo de vida da parcela

1

PENDING — sem billId

A compra aparece nas transações correntes (últimos 7 dias) com status=PENDING e sem creditCardMetadata.billId — a fatura ainda está aberta.
2

POSTED — billId definido

Quando o extrato fecha, a transação vira status=POSTED e creditCardMetadata.billId é preenchido. Essa transição dispara o webhook transactions/updated.
3

Leitura por fatura

As transações de uma fatura fechada específica são lidas pelo filtro legado GET /transactions?accountId={accountId}&billId={billId}.
Como não há id de agrupamento, junte as parcelas de uma mesma compra heuristicamente por (merchantName, totalAmount, totalInstallments, purchaseDate). E assine transactions/created e transactions/updated para capturar parcelas que caem fora da janela corrente de 7 dias.

Convenção de sinal do amount no cartão

Em contas de cartão (type=CREDIT) o sinal de amount é invertido em relação a contas bancárias, mas o campo type continua normalizado para a perspectiva do titular:
Em contas bancárias (type=BANK) é o oposto: débitos são negativos e créditos positivos, e o sinal sempre concorda com type. Trate cada tipo de conta separadamente ao somar gastos.

Gotchas por instituição

Algumas instituições expõem parcelamentos de formas diferentes. Trate estes casos explicitamente ao consolidar gastos:
O BTG traz todas as parcelas futuras já como transações PENDING. Se você somar tudo sem filtrar por status, vai contar gastos que ainda não ocorreram. Para o gasto do mês, use apenas as parcelas POSTED (ou o installmentNumber corrente).
A XP traz o valor total da compra (não o valor da parcela individual). Antes de somar, cheque creditCardMetadata.totalInstallments/installmentNumber e divida pelo total de parcelas para não inflar o gasto.

Próximos passos

Sincronizar transações

Paginação por cursor e atualização incremental com createdAtFrom.

Reconciliação

Webhooks + job noturno para nunca perder uma transição PENDING→POSTED.