ConnectWiz + API ਅਤੇ Webhooks
ਲਾਈਵ ਇੰਟੀਗ੍ਰੇਸ਼ਨਜੋ API ਅਸੀਂ ਵੇਚਦੇ ਹਾਂ, ਉਹੀ API ਅਸੀਂ ਖੁਦ ਵਰਤਦੇ ਹਾਂ
ਪੂਰਾ ਪਲੇਟਫ਼ਾਰਮ ਇੱਕੋ OpenAPI ਇਕਰਾਰ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਹੈ, ਅਤੇ ਸਾਡਾ ਆਪਣਾ ਪੈਨਲ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਉਸੇ ਤੋਂ ਬਣਦੇ ਹਨ — ਨਾ ਕੋਈ ਲੁਕਵਾਂ endpoint, ਨਾ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਕੋਡ ਵਿੱਚ ਫ਼ਰਕ। ਇਸ ਦੇ ਉੱਪਰ: ਸੀਮਤ scope ਵਾਲੀਆਂ Commerce API ਕੁੰਜੀਆਂ, ਸੁਰੱਖਿਅਤ webhook ਟ੍ਰਿਗਰ, ਅਤੇ ਤੁਹਾਡੇ ਸਿਸਟਮਾਂ ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੇ ਫ਼ਲੋ।
ਡਿਵੈਲਪਰ
ਇਹ ਠੀਕ-ਠੀਕ ਕੀ ਕਰਦਾ ਹੈ
ਇੱਕੋ ਅਧਿਕਾਰਤ ਇਕਰਾਰ
ਇੱਕੋ OpenAPI 3 ਦਸਤਾਵੇਜ਼ ਪਲੇਟਫ਼ਾਰਮ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ; ਸਾਡੇ ਆਪਣੇ TypeScript ਕਲਾਇੰਟ ਉਸੇ ਤੋਂ ਬਣਦੇ ਹਨ — ਦਸਤਾਵੇਜ਼ ਹਕੀਕਤ ਤੋਂ ਵੱਖ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਕਿਉਂਕਿ ਹਕੀਕਤ ਬਣਦੀ ਹੀ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਹੈ।
Commerce API ਕੁੰਜੀਆਂ
ਵਰਕਸਪੇਸ ਵੱਲੋਂ ਜਾਰੀ ਕੀਤੀਆਂ, ਸਾਫ਼ ਲਿਖੇ scope ਵਾਲੀਆਂ ਕੁੰਜੀਆਂ — ਕੈਟਾਲਾਗ ਪੜ੍ਹਨਾ, ਆਰਡਰ ਪੜ੍ਹਨਾ, ਆਰਡਰ ਲਿਖਣਾ — ਤੁਹਾਡੇ ਆਪਣੇ ਸਟੋਰਫ਼੍ਰੰਟ ਜਾਂ ਐਪ ਨੂੰ ਉਸੇ ਆਰਡਰ ਇੰਜਣ 'ਤੇ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਕੀਮਤਾਂ ਹਮੇਸ਼ਾ ਸਰਵਰ 'ਤੇ ਹੀ ਤੈਅ ਹੁੰਦੀਆਂ ਹਨ।
ਇਨਬਾਊਂਡ webhook, ਸੁਰੱਖਿਅਤ
ਹਰ ਫ਼ਲੋ webhook ਟ੍ਰਿਗਰ ਦਾ ਆਪਣਾ URL ਅਤੇ secret ਹੁੰਦਾ ਹੈ, ਕੱਚੀ body 'ਤੇ HMAC ਤਸਦੀਕ ਹੁੰਦੀ ਹੈ ਅਤੇ ਰੀਪਲੇਅ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ। Payload ਕਿਸੇ ਵਿਅਕਤੀ ਦਾ ਨਾਂ ਲੈ ਸਕਦਾ ਹੈ; ਫ਼ਲੋ ਦੇ ਅੰਦਰੂਨੀ ਕੰਮਕਾਜ ਨੂੰ ਕਦੇ ਮੋੜ ਨਹੀਂ ਸਕਦਾ।
ਫ਼ਲੋ ਰਾਹੀਂ ਆਊਟਬਾਊਂਡ
REST ਕਦਮ ਤੁਹਾਡੇ ਸਿਸਟਮਾਂ ਨੂੰ ਠੀਕ ਉਨ੍ਹਾਂ ਪਲਾਂ 'ਤੇ ਕਾਲ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕੈਨਵਸ 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ — ਆਰਡਰ ਦਿੱਤਾ ਗਿਆ, ਸਹਿਮਤੀ ਮਿਲੀ, ਬੁਕਿੰਗ ਹੋਈ।
ਤਕਨੀਕੀ ਪੱਖ
API ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਸਾਡੇ ਫ਼ੈਸਲੇ, ਸਾਫ਼ ਲਿਖੇ
ਕੀਮਤਾਂ ਕਦੇ ਕਲਾਇੰਟ ਤੋਂ ਨਹੀਂ ਆਉਂਦੀਆਂ
ਆਰਡਰ ਦੀ ਬੇਨਤੀ ਸਿਰਫ਼ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਕੀ ਅਤੇ ਕਿੰਨਾ — ਨਾਂ ਅਤੇ ਕੀਮਤ ਉਸੇ ਪਲ ਸਰਵਰ 'ਤੇ ਕੈਟਾਲਾਗ ਵਿੱਚੋਂ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਲਾਈਨ ਉੱਤੇ ਸਨੈਪਸ਼ਾਟ ਵਜੋਂ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਛੇੜਛਾੜ ਵਾਲੀ ਬੇਨਤੀ ਕੋਈ ਛੋਟ ਨਹੀਂ ਘੜ ਸਕਦੀ।
ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਸਮਰੱਥਾ
ਹਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਆਪਣਾ ਸਮਰੱਥਾ-ਇਕਰਾਰ ਛਾਪਦੀ ਹੈ — ਕੀ ਇਹ ਫ਼ੋਨ ਨੰਬਰ ਨਾਲ ਮਿਲਾਨ ਕਰ ਸਕਦੀ ਹੈ, ਮਹਿਮਾਨ ਆਰਡਰਾਂ ਦੀ ਸੂਚੀ ਦੇ ਸਕਦੀ ਹੈ, ਆਰਡਰ ਬਣਾ ਸਕਦੀ ਹੈ? — ਅਤੇ ਐਲਾਨੇ ਹੋਏ "ਨਹੀਂ" ਦੇ ਬਾਵਜੂਦ ਕਾਲ ਕਰਨ 'ਤੇ ਗਲਤੀ ਤੁਰੰਤ ਆਉਂਦੀ ਹੈ, ਕਿਤੇ ਡੂੰਘਾਈ ਵਿੱਚ ਜਾ ਕੇ ਨਾਕਾਮ ਹੋਣ ਦੀ ਥਾਂ।
ਗਲਤੀਆਂ, ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਮਤਲਬ ਹੈ
ਟ੍ਰਾਂਸਪੋਰਟ ਪਰਤ "ਇਜਾਜ਼ਤ ਨਹੀਂ" ਅਤੇ "ਸੇਵਾ ਬੰਦ ਹੈ" ਵਿੱਚ ਫ਼ਰਕ ਕਰਦੀ ਹੈ — ਇਸ ਲਈ "ਦੁਕਾਨ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਹੋ ਰਹੀ" ਕਦੇ ਵੀ "ਇਸ ਗਾਹਕ ਨੇ ਕਦੇ ਕੁਝ ਨਹੀਂ ਖਰੀਦਿਆ" ਬਣ ਕੇ ਨਹੀਂ ਦਿਸਦਾ। ਨਾਂ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਹੀ API ਅਤੇ ਅੰਦਾਜ਼ੇ ਦੀ ਖੇਡ ਵਿਚਲਾ ਫ਼ਰਕ ਹਨ।
ਰੀਪਲੇਅ ਤੋਂ ਸੁਰੱਖਿਅਤ webhook
ਹਰ ਆਉਣ ਵਾਲਾ ਇਵੈਂਟ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਪਹਿਲਾਂ idempotency ਲੈਜਰ ਵਿੱਚ ਆਪਣੀ ਵਿਲੱਖਣ ਕੁੰਜੀ ਦਰਜ ਕਰਦਾ ਹੈ — ਦੁਬਾਰਾ ਭੇਜੀ ਜਾਂ ਦੁਹਰਾਈ ਗਈ ਡਿਲੀਵਰੀ ਡਾਟਾਬੇਸ ਦੀ ਪਰਤ 'ਤੇ ਹੀ ਦਮ ਤੋੜ ਦਿੰਦੀ ਹੈ, ਤੁਹਾਡੀ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ।
ਕੁੰਜੀਆਂ ਹੈਸ਼ ਵਿੱਚ, secret ਸੀਮਤ ਦਾਇਰੇ ਵਿੱਚ
API ਕੁੰਜੀਆਂ ਹੈਸ਼ ਵਜੋਂ ਸਟੋਰ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਦਰਵਾਜ਼ੇ 'ਤੇ ਸਿਰਫ਼ ਹੈਸ਼ ਅਤੇ scope ਹੀ ਪੜ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ — ਲੀਕ ਹੋਈ ਡਾਟਾਬੇਸ ਲਾਈਨ ਕਿਸੇ ਵਰਕਸਪੇਸ ਦਾ ਨਾਂ ਨਹੀਂ ਦੱਸਦੀ ਅਤੇ ਆਪਣੇ scope ਤੋਂ ਅੱਗੇ ਕੁਝ ਨਹੀਂ ਖੋਲ੍ਹਦੀ।
ਡਰਾਫ਼ਟ ਅਤੇ ਪੁਸ਼ਟੀ, ਦੋਵੇਂ ਸਾਫ਼
ਆਰਡਰ ਬਣਾਉਣ ਵੇਲੇ confirm ਪੈਰਾਮੀਟਰ ਸਾਫ਼-ਸਾਫ਼ ਦੇਣਾ ਪੈਂਦਾ ਹੈ — ਜਨਤਕ API ਵਿੱਚ ਡਿਫ਼ਾਲਟ ਪੁਸ਼ਟੀਸ਼ੁਦਾ ਹੈ, ਪੈਨਲ ਦੇ ਫ਼ਲੋ ਡਰਾਫ਼ਟ ਬਣਾ ਕੇ ਰੱਖ ਸਕਦੇ ਹਨ — ਇਸ ਲਈ "ਕੀ ਇਹ ਅਸਲੀ ਹੈ?" ਇੱਕ ਫ਼ੀਲਡ ਹੈ, ਕੋਈ ਅਣਲਿਖੀ ਰਵਾਇਤ ਨਹੀਂ।
ਸੈੱਟਅੱਪ
ਇਹ ਕਿਵੇਂ ਜੁੜਦਾ ਹੈ
ਕੁੰਜੀ ਜਾਰੀ ਕਰੋ
ਪੈਨਲ ਵਿੱਚ ਸੀਮਤ scope ਵਾਲੀ Commerce API ਕੁੰਜੀ ਬਣਾਓ; ਰੱਦ ਵੀ ਓਨੀ ਹੀ ਆਸਾਨੀ ਨਾਲ ਕਰੋ।
Webhook ਜੋੜੋ
webhook ਟ੍ਰਿਗਰ ਵਾਲਾ ਫ਼ਲੋ ਬਣਾਓ; ਬੇਨਤੀਆਂ 'ਤੇ ਉਸ ਦੇ secret ਨਾਲ ਦਸਤਖਤ ਕਰੋ।
ਵਾਪਸ ਕਾਲ ਕਰੋ
ਜਿੱਥੇ ਤੁਹਾਡੇ ਸਿਸਟਮਾਂ ਨੂੰ ਖਬਰ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ, ਉੱਥੇ REST ਕਦਮ ਜੋੜੋ।
ਇਕੱਠੇ ਬਿਹਤਰ
ਇਹ ਕਿਨ੍ਹਾਂ ਨਾਲ ਜੁੜਦਾ ਹੈ
Flows
Webhook ਟ੍ਰਿਗਰ ਇਨ੍ਹਾਂ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹਨ: ਫ਼ਲੋ; REST ਕਦਮ ਤੁਹਾਡੇ ਸਿਸਟਮਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਪਲਾਂ 'ਤੇ ਵਾਪਸ ਕਾਲ ਕਰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਬਣਾਉਂਦੇ ਹੋ — ਇਨਬਾਊਂਡ ਅਤੇ ਆਊਟਬਾਊਂਡ ਆਟੋਮੇਸ਼ਨ ਇੱਕੋ ਕੈਨਵਸ 'ਤੇ ਰਹਿੰਦੀਆਂ ਹਨ।
ਕਾਮਰਸ
ਸਾਡਾ ਕੈਟਾਲਾਗ ਅਤੇ ਆਰਡਰ ਇੰਜਣ ਹੀ API ਦੇ ਪਿੱਛੇ ਕੰਮ ਕਰਦਾ ਹੈ — ਉਹੀ, ਜਿਸ ਨੂੰ ਚੈਟ ਸ਼ਾਪ ਅਤੇ AI ਵਰਤਦੇ ਹਨ: ਆਰਡਰਾਂ ਦਾ ਇੱਕੋ ਸੱਚ, ਚਾਰ ਦਰਵਾਜ਼ੇ।
ਤੁਹਾਡਾ ਆਪਣਾ ਸਟੋਰਫ਼੍ਰੰਟ
ਟੀਮਾਂ ਅੱਜ ਹੀ Commerce API 'ਤੇ headless ਸਟੋਰਫ਼੍ਰੰਟ ਚਲਾ ਰਹੀਆਂ ਹਨ — ਇਹ ਉਹੀ ਰਾਹ ਹੈ ਜਿਸ ਦੀ ਸਿਫ਼ਾਰਸ਼ Shopify ਪੇਜ ਇਮਾਨਦਾਰੀ ਨਾਲ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਨੇਟਿਵ ਕਨੈਕਟਰ ਬਣ ਰਿਹਾ ਹੈ।
ਸੁਰੱਖਿਆ ਅਤੇ ਗਾਰੰਟੀਆਂ
ਅਕਾਊ ਗਾਰੰਟੀਆਂ
ਕੱਚੀ body 'ਤੇ HMAC
Webhook ਦੀ ਤਸਦੀਕ ਕੱਚੀ ਬੇਨਤੀ body 'ਤੇ ਹਰ ਟ੍ਰਿਗਰ ਦੇ ਆਪਣੇ secret ਨਾਲ ਦਸਤਖਤ ਕਰਦੀ ਹੈ ਅਤੇ constant time ਵਿੱਚ ਤੁਲਨਾ ਕਰਦੀ ਹੈ — ਪਾਰਸਿੰਗ ਸਬੂਤ ਮਿਲਣ ਤੋਂ ਬਾਅਦ ਹੀ ਹੁੰਦੀ ਹੈ।
Payload ਡਾਟਾ ਹੈ, ਹੁਕਮ ਕਦੇ ਨਹੀਂ
Webhook payload ਕਿਸੇ ਵਿਅਕਤੀ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ; ਉਹ ਫ਼ਲੋ ਦੇ ਅੰਦਰੂਨੀ ਕੰਮਕਾਜ ਨੂੰ ਕਦੇ ਮੋੜ ਨਹੀਂ ਸਕਦਾ, ਪ੍ਰੌਂਪਟ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖ ਸਕਦਾ, ਟੂਲ ਨਹੀਂ ਚਲਾ ਸਕਦਾ। ਡਾਟਾ ਅਤੇ ਹਦਾਇਤਾਂ ਵਿਚਲੀ ਹੱਦ ਢਾਂਚੇ ਵਿੱਚ ਹੈ, ਵਿਹਾਰ ਦੇ ਭਰੋਸੇ ਨਹੀਂ।
ਹਰ ਦਰਵਾਜ਼ੇ 'ਤੇ ਦਰ ਦੀਆਂ ਹੱਦਾਂ
ਜਨਤਕ endpoint ਸਟੈਂਡਰਡ ਥ੍ਰੌਟਲਿੰਗ ਹੇਠ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਪੜ੍ਹਨ ਦੀਆਂ ਹੱਦਾਂ ਸਰਵਰ 'ਤੇ ਤੈਅ ਹੁੰਦੀਆਂ ਹਨ — ਗਲਤ ਵਿਹਾਰ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਆਪਣਾ ਹੀ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ, ਪਲੇਟਫ਼ਾਰਮ ਦਾ ਨਹੀਂ।
ਬਾਰੀਕੀਆਂ, ਇਮਾਨਦਾਰੀ ਨਾਲ
ਹੱਦਾਂ, ਸਾਫ਼ ਲਿਖੀਆਂ
ਅਜੇ ਕੋਈ firehose ਨਹੀਂ
ਸਭ ਕੁਝ ਸਬਸਕ੍ਰਾਈਬ ਕਰਨ ਵਾਲੀ ਆਮ webhook ਫ਼ੀਡ ਨਹੀਂ ਬਣੀ — ਅੱਜ ਆਊਟਬਾਊਂਡ ਇਵੈਂਟ ਫ਼ਲੋ ਦੇ ਕਦਮਾਂ ਰਾਹੀਂ ਹੁੰਦੇ ਹਨ। ਇਹ ਇੱਥੇ ਲਿਖਿਆ ਹੈ, ਤਾਂ ਜੋ ਕਿਸੇ ਸੇਲਜ਼ ਕਾਲ ਨੂੰ ਕੁਝ ਹੋਰ ਇਸ਼ਾਰਾ ਨਾ ਕਰਨਾ ਪਵੇ।
ਸੀਮਤ ਰੀਡ, ਜਾਣ-ਬੁੱਝ ਕੇ
ਇੱਕ ਰੀਡ ਕਰਸਰ ਨਾਲ ਵੱਧ ਤੋਂ ਵੱਧ 100 ਰਿਕਾਰਡ ਦਿੰਦੀ ਹੈ — API ਰੋਜ਼ਾਨਾ ਕੰਮਕਾਜੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਲਈ ਬਣਿਆ ਹੈ, ਥੋਕ ਐਕਸਪੋਰਟ ਲਈ ਨਹੀਂ। ਥੋਕ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਗੱਲ ਕਰੋ — ਚੋਰ-ਮੋਰੀ ਨਾ ਲੱਭੋ।
ਇਮਾਨਦਾਰੀ ਨਾਲ ਜੁੜਨਾ, ਰੌਲਾ ਪਾ ਕੇ ਜੁੜਨ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।
ਇੱਥੇ ਹਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਨੂੰ ਉਸੇ ਹਿਸਾਬ ਨਾਲ ਦੱਸਿਆ ਗਿਆ ਹੈ ਜੋ ਉਹ ਅਸਲ ਵਿੱਚ ਕਰਦੀ ਹੈ — ਦਿਸ਼ਾ, ਮਾਲਕੀ ਅਤੇ ਹੱਦਾਂ ਸਮੇਤ।