ConnectWiz + API & Webhook

Integrasi aktif

API yang kami jual adalah API yang kami pakai

Seluruh platformnya dispesifikasikan dalam satu kontrak OpenAPI yang darinya panel dan aplikasi mobile kami sendiri dihasilkan — tanpa endpoint bayangan, tanpa dokumentasi yang melenceng. Di atasnya: kunci Commerce API ber-scope, pemicu webhook terjamin, dan alur yang memanggil sistem Anda.

Satu kontrak OpenAPI Kunci API ber-scope Webhook terverifikasi HMAC
API & Webhook × ConnectWiz
Payload itu data, tidak pernah perintah
Kunci ber-scope: baca katalog · tulis pesanan
Webhook → HMAC terverifikasi → alur dimulai
Langkah REST pada alur memanggil API Anda
1
Kontrak OpenAPI yang jadi rujukan — berkas yang sama dengan sumber panel dan aplikasi mobile kami sendiri
3
Scope commerce — baca katalog, baca pesanan, tulis pesanan — diterbitkan per kunci
100
Baris maksimum per pembacaan, dijepit di sisi server — parameter limit divalidasi, tidak pernah dipercaya begitu saja
50
Baris item per pesanan lewat API — batas yang dinyatakan, bukan yang ditemukan sendiri

Developer

Apa yang dilakukannya — persisnya

Satu kontrak yang jadi rujukan

Satu dokumen OpenAPI 3 menspesifikasikan platformnya; klien TypeScript kami sendiri dihasilkan darinya — dokumentasinya tidak mungkin melenceng dari kenyataan, karena kenyataannya dibangun dari dokumentasi itu.

Kunci Commerce API

Kunci yang diterbitkan tenant dengan scope eksplisit — baca katalog, baca pesanan, tulis pesanan — menggerakkan etalase atau aplikasi Anda sendiri di atas mesin pesanan yang sama, dengan harga yang selalu ditentukan di sisi server.

Webhook masuk, diamankan

Setiap pemicu webhook alur punya URL dan secret-nya sendiri, verifikasi HMAC atas body mentahnya, dan perlindungan replay. Sebuah payload boleh menyebut nama seseorang; ia tidak pernah boleh menyetir isi dalam alurnya.

Jalur keluar lewat alur

Langkah REST memanggil sistem Anda persis di momen yang Anda gambar di kanvas — pesanan dibuat, persetujuan diberikan, pemesanan terjadi.

Sisi teknis

Sikap desain API, dinyatakan

Harga tidak pernah datang dari klien

Permintaan pesanan menyebut apa dan berapa banyak — nama dan harganya dibaca dari katalog saat itu juga, di sisi server, lalu ditulis ke barisnya sebagai potret. Permintaan yang dirusak tidak bisa mengarang diskon.

Kemampuan dulu, baru panggilan

Tiap titik tampil integrasi menerbitkan kontrak kemampuan — bisakah ia mencocokkan lewat nomor telepon, mendaftar pesanan tamu, membuat pesanan? — dan memanggil melewati "tidak" yang sudah dinyatakan langsung melempar error, bukan gagal di suatu tempat yang dalam.

Error yang berarti sesuatu

Lapisan transportnya membedakan "tidak berwenang" dari "layanan mati" — sehingga "tokonya tidak bisa dihubungi" tidak pernah ditampilkan sebagai "pelanggan ini tidak pernah membeli apa pun". Error yang disebut namanya adalah beda antara sebuah API dan tebak-tebakan.

Webhook antireplay

Setiap event masuk mengklaim kunci unik di catatan idempotensi sebelum diproses — kiriman yang dicoba ulang atau diputar ulang mati di lapisan basis data, bukan di dalam otomatisasi Anda.

Kunci di-hash, secret diberi scope

Kunci API disimpan sebagai hash, dan hanya hash beserta scope-nya yang bisa dipecahkan di depan pintu — baris basis data yang bocor tidak menyebut workspace mana pun dan tidak membuka apa pun di luar scope-nya.

Draf dan konfirmasi dinyatakan eksplisit

Pembuatan pesanan menerima parameter konfirmasi yang eksplisit — API publik bawaannya terkonfirmasi, alur di panel bisa menyiapkan draf — sehingga "ini sungguhan atau bukan?" adalah sebuah field, bukan kebiasaan tak tertulis.

Penyiapan

Cara menyambungnya

01

Terbitkan sebuah kunci

Buat kunci Commerce API ber-scope di panel; mencabutnya pun sama gampangnya.

02

Pasang sebuah webhook

Buat alur dengan pemicu webhook; tandatangani permintaannya dengan secret milik pemicu itu.

03

Panggil keluar

Tambahkan langkah REST di titik tempat sistem Anda perlu diberi kabar.

Lebih baik bersama

Apa yang bisa dipadukan

Flows

Pemicu webhook memulai alur; langkah REST memanggil balik sistem Anda di momen-momen yang Anda gambar sendiri — otomatisasi masuk dan keluar berbagi satu kanvas.

Commerce

Mesin katalog dan pesanan di balik API-nya sama dengan yang dipakai toko obrolan dan AI — satu kebenaran pesanan, empat pintu.

Etalase milik Anda sendiri

Sejumlah tim menjalankan etalase headless di atas Commerce API hari ini — jalur yang secara jujur direkomendasikan halaman Shopify selama konektor nativenya masih dibangun.

Keamanan & jaminan

Jaminan yang membosankan

HMAC atas body mentahnya

Verifikasi webhook menandatangani body mentah permintaannya dengan secret per pemicu lalu membandingkannya dalam waktu konstan — penguraian baru terjadi setelah ada bukti.

Payload itu data, tidak pernah perintah

Payload webhook boleh merujuk seseorang; ia tidak pernah boleh menyetir isi dalam sebuah alur, menulis ulang prompt, atau memanggil perkakas. Batas antara data dan instruksi itu bersifat arsitektural, bukan perilaku.

Batas laju di setiap pintu

Endpoint publik memakai pembatasan laju standar, dan batas pembacaan dijepit di sisi server — klien yang berulah merugikan dirinya sendiri, bukan platformnya.

Ketentuan kecilnya, apa adanya

Batas-batas, dinyatakan

Belum ada saluran serba-kirim

Feed webhook generik yang berlangganan-semuanya belum dibangun — hari ini event keluar terjadi lewat langkah alur. Dinyatakan di sini, supaya tidak ada panggilan penjualan yang perlu menyiratkan sebaliknya.

Pembacaan yang dibatasi, sejak rancangannya

Pembacaan mengembalikan maksimal 100 baris dengan kursor — API-nya dibangun untuk integrasi operasional, bukan ekspor massal. Kebutuhan massal itu bahan percakapan, bukan celah untuk diakali.

FAQ API & Webhook

Jawaban langsung

Selengkapnya di halaman FAQ, atau tanyakan langsung kepada kami.

Platformnya dispesifikasikan dalam satu kontrak OpenAPI 3 — berkas yang sama dengan sumber tipe panel web dan aplikasi mobile kami. Yang Anda jadikan sasaran integrasi adalah yang kami jalankan sendiri.

Secret per pemicu, verifikasi HMAC atas body mentahnya, dan perlindungan replay lewat catatan idempotensi. Dan sudah jadi aturan bahwa payload itu data: ia boleh merujuk seseorang, tidak pernah boleh memerintah otomatisasinya.

Bisa, lewat langkah REST pada alur, yang menyala di momen-momen yang Anda pilih di kanvas. Feed webhook keluar yang generik ada di roadmap dan sengaja tidak dijanjikan sampai benar-benar dirilis.

Bisa — pembacaan katalog dan penulisan pesanan adalah jalur yang didukung, dengan harga yang ditentukan di sisi server dan kunci ber-scope yang bisa Anda cabut per titik tampil. Batas 50 baris item dan 100 baris data dinyatakan supaya Anda merancang dengan memperhitungkannya, bukan tersandung karenanya.

Pengiriman bersifat idempoten di sisi kami — catatannya mengenali kiriman ulang lalu membuangnya, jadi sistem Anda aman untuk mencoba lagi. Langkah REST keluar dari alur membawa kebijakan percobaan ulangnya sendiri, dengan kegagalannya ditampilkan pada jalannya alur itu.

Terhubung secara jujur lebih berharga daripada terhubung secara berisik.

Setiap integrasi di sini dijelaskan menurut apa yang benar-benar dilakukannya — lengkap dengan arah, kepemilikan, dan batasnya.