---
title: Kredit dan penagihan
source: https://se-hari.com/docs/kredit
updated: 2026-08-16T01:05:08.376184+00:00
---

> Kredit adalah satuan penagihan Se-Hari. Kapan dipotong, bagaimana menghitungnya di depan, dan kenapa notulen ditagih belakangan.

Se-Hari tidak memakai langganan bulanan. Anda membeli **kredit** sekali pakai, dan kredit terpotong saat Anda memakai layanan. API memakai saldo yang sama persis dengan dashboard — tidak ada tarif terpisah, tidak ada biaya akses API.

## Dua perilaku penagihan yang berbeda

Ini perbedaan yang paling sering menimbulkan kebingungan, jadi ada baiknya dipahami sejak awal.

**Meeting memotong kredit saat itu juga.** Begitu `POST /meetings` berhasil, kredit sudah berkurang. Biayanya pasti, karena diambil dari paket harga yang sudah tetap.

**Notulen ditagih setelah selesai.** `POST /notes` hanya mengantre pekerjaan; kredit belum berkurang sedikit pun. Penagihan terjadi ketika pemrosesan selesai, dan dihitung dari **durasi asli rekaman** — bukan dari durasi yang Anda perkirakan.

Konsekuensi praktisnya: kalau workflow Anda membaca saldo tepat setelah mengantre notulen, angkanya belum berubah. Itu bukan bug.

## Menghitung biaya di depan

`POST /credits/estimate` menghitung biaya sebuah operasi tanpa menjalankannya dan tanpa efek samping apa pun.

```bash
curl -X POST "https://se-hari.com/api/v1/credits/estimate" \
  -H "Authorization: Bearer $SEHARI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "notulen", "duration_minutes": 60}'
```

```json
{
  "credits_required": 3,
  "credits_available": 74,
  "sufficient": true,
  "is_estimate": true,
  "breakdown": { "minutes_per_credit": 20, "duration_minutes": 60 }
}
```

Perhatikan `is_estimate`. Untuk notulen nilainya `true`, karena yang ditagih nanti adalah durasi asli hasil transkripsi. Untuk meeting nilainya `false` — biayanya pasti.

Tarif notulen dibaca dari konfigurasi, bukan di-hardcode, dan `breakdown.minutes_per_credit` memberi tahu tarif yang berlaku saat itu. Jangan menyalin angkanya ke dalam kode Anda.

## Melihat saldo

```bash
curl "https://se-hari.com/api/v1/credits" \
  -H "Authorization: Bearer $SEHARI_API_KEY"
```

Yang penting bukan hanya `balance`, tapi juga `packages`:

```json
{
  "balance": 74,
  "packages": [
    { "credits_remaining": 24, "expires_at": "2026-09-30T23:59:59Z" },
    { "credits_remaining": 50, "expires_at": "2027-12-31T23:59:59Z" }
  ]
}
```

Kredit punya masa berlaku, dan dipotong dari **paket yang paling cepat hangus lebih dulu**. Saldo 74 yang sebagian besar hangus bulan depan adalah situasi yang sangat berbeda dari saldo 74 yang berlaku setahun — dan hanya rincian per paket yang bisa membedakannya.

## Riwayat pemakaian

`GET /credits/usage` menelusuri ke mana kredit terpakai, berpaginasi cursor seperti daftar lain. Setiap baris menyebutkan jumlah, deskripsi, dan waktunya. Refund muncul sebagai jumlah negatif.

```bash
curl "https://se-hari.com/api/v1/credits/usage?limit=20" \
  -H "Authorization: Bearer $SEHARI_API_KEY" | jq '.data[] | {credits, description, created_at}'
```

## Refund

Membatalkan meeting yang **belum dimulai** mengembalikan kreditnya. Yang sudah berjalan tidak — waktu host Zoom sudah terpakai dan tidak bisa ditarik kembali.

Karena itu `DELETE /meetings/{id}` menjawab berbeda tergantung status, dan itu bukan kesalahan pemanggil. Periksa `status` meeting lebih dulu kalau workflow Anda perlu memutuskan sesuatu berdasarkan hasilnya.

Membatalkan meeting yang sudah dibatalkan ditolak, bukan mengembalikan kredit untuk kedua kalinya.

## Saat kredit habis

`403 insufficient_credits` bukan kegagalan teknis melainkan kondisi bisnis. Retry otomatis tidak akan pernah menyelesaikannya — tidak ada yang berubah di antara dua percobaan kecuali kuota rate limit Anda yang menipis.

Yang benar: hentikan sisa antrean dan beri tahu manusia. Event webhook `credit.low` ada justru untuk memberi peringatan sebelum titik ini tercapai.

## Batas kredit harian per key

Setiap API key bisa diberi batas kredit harian di dashboard. Melewatinya menghasilkan `403 credit_cap_exceeded` — berbeda dari `insufficient_credits`, karena saldo Anda masih ada.

Ini pengaman termurah yang tersedia terhadap key yang bocor atau perulangan yang salah tulis. Pasang di setiap key, bukan hanya di yang terlihat berisiko; angkanya cukup beberapa kali lipat pemakaian normal.

## Selanjutnya

- [`insufficient_credits`](/docs/error/insufficient-credits) — penanganan lengkap
- [`credit_cap_exceeded`](/docs/error/credit-cap-exceeded) — batas per key
- [Autentikasi](/docs/autentikasi) — mengatur batas harian