@proveanything/smartlinks 1.15.2 → 1.15.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/api/ai.js CHANGED
@@ -28,7 +28,11 @@ var aiInternal;
28
28
  * @returns Responses API result or async iterable for streaming events
29
29
  */
30
30
  async function create(collectionId, request) {
31
+ var _a;
31
32
  const path = `/admin/collection/${encodeURIComponent(collectionId)}/ai/v1/responses`;
33
+ if (((_a = request.multi_agent) === null || _a === void 0 ? void 0 : _a.enabled) && request.stream) {
34
+ throw new Error('Streaming is not supported when multi_agent.enabled is true');
35
+ }
32
36
  if (request.stream) {
33
37
  return requestStream(path, { method: 'POST', body: request });
34
38
  }
@@ -1,6 +1,6 @@
1
1
  # Smartlinks API Summary
2
2
 
3
- Version: 1.15.2 | Generated: 2026-07-05T07:39:20.416Z
3
+ Version: 1.15.4 | Generated: 2026-07-14T15:01:53.978Z
4
4
 
5
5
  This is a concise summary of all available API functions and types.
6
6
 
@@ -42,6 +42,7 @@ For detailed guides on specific features:
42
42
  - **[Portal Back Button](portal-back-button.md)** - `parentPath` contract for hierarchy-aware "up" navigation; `useDeepLinkSync` integration
43
43
  - **[Contact Search](contact-search.md)** - Admin contact search: free-text, typeahead, identity/tag/JSONB filters, and pagination
44
44
  - **[App Data Storage](app-data-storage.md)** - User-specific and collection-scoped app data storage
45
+ - **[Product/Proof Data Scoping](proof-product-data-scoping.md)** - Canonical spec for `product.data`/`.admin` and `proof.data`/`.admin`/`.values` (owner/personal) buckets, read/write authority, and the `productFields`/`proofFields` collection-settings schemas
45
46
  - **[Forms](forms.md)** - Platform-managed form definitions, submissions, and schema-driven React form UI
46
47
  - **[App Objects: Cases, Threads & Records](app-objects.md)** - Generic app-scoped building blocks for support cases, discussions, bookings, registrations, and more
47
48
  - **[App Records Pattern](app-records-pattern.md)** - Canonical pattern for storing per-product, per-facet, or rule-targeted app data
@@ -499,6 +500,8 @@ interface ResponseTool {
499
500
  name?: string
500
501
  description?: string
501
502
  parameters?: Record<string, any>
503
+ output_schema?: Record<string, any>
504
+ allowed_callers?: Array<'assistant' | 'programmatic'>
502
505
  [key: string]: any
503
506
  }
504
507
  ```
@@ -544,6 +547,11 @@ interface ResponsesRequest {
544
547
  text?: Record<string, any>
545
548
  metadata?: Record<string, string>
546
549
  prompt_cache_key?: string
550
+ multi_agent?: {
551
+ enabled: boolean
552
+ max_concurrent_subagents?: number
553
+ }
554
+ service_tier?: 'auto' | 'standard' | 'flex' | 'priority'
547
555
  }
548
556
  ```
549
557
 
@@ -6939,6 +6947,37 @@ interface ProductQueryResponse {
6939
6947
  }
6940
6948
  ```
6941
6949
 
6950
+ **ScopedFieldOption** (interface)
6951
+ ```typescript
6952
+ interface ScopedFieldOption {
6953
+ value: string
6954
+ label: string
6955
+ }
6956
+ ```
6957
+
6958
+ **ScopedFieldDef** (interface)
6959
+ ```typescript
6960
+ interface ScopedFieldDef {
6961
+ key: string
6962
+ label: string
6963
+ type: ScopedFieldType
6964
+ required?: boolean
6965
+ placeholder?: string
6966
+ help?: string
6967
+ options?: ScopedFieldOption[]
6968
+ defaultValue?: JsonValue
6969
+ showInTable?: boolean
6970
+ showInDetail?: boolean
6971
+ }
6972
+ ```
6973
+
6974
+ **ProductFieldsConfig** (interface)
6975
+ ```typescript
6976
+ interface ProductFieldsConfig {
6977
+ fields: ProductFieldDef[]
6978
+ }
6979
+ ```
6980
+
6942
6981
  **JsonPrimitive** = `string | number | boolean | null`
6943
6982
 
6944
6983
  **JsonValue** = ``
@@ -6955,8 +6994,23 @@ interface ProductQueryResponse {
6955
6994
 
6956
6995
  **ProductUpdateRequest** = `Partial<Omit<ProductWriteInput, 'id'>>`
6957
6996
 
6997
+ **ScopedFieldType** = ``
6998
+
6999
+ **ProductFieldScope** = `'public' | 'admin'`
7000
+
7001
+ **ProductFieldDef** = `ScopedFieldDef & { scope?: ProductFieldScope }`
7002
+
6958
7003
  ### proof
6959
7004
 
7005
+ **ProofValues** (interface)
7006
+ ```typescript
7007
+ interface ProofValues {
7008
+ [key: string]: JsonValue | Record<string, JsonValue> | Record<string, Record<string, JsonValue>> | undefined
7009
+ owner?: Record<string, JsonValue>
7010
+ personal?: Record<string, Record<string, JsonValue>>
7011
+ }
7012
+ ```
7013
+
6960
7014
  **Proof** (interface)
6961
7015
  ```typescript
6962
7016
  interface Proof {
@@ -6968,25 +7022,40 @@ interface Proof {
6968
7022
  userId: string
6969
7023
  claimable?: boolean
6970
7024
  virtual?: boolean
6971
- values: Record<string, any>
7025
+ data?: Record<string, JsonValue>
7026
+ admin?: Record<string, JsonValue>
7027
+ values: ProofValues
6972
7028
  }
6973
7029
  ```
6974
7030
 
6975
7031
  **ProofCreateRequest** (interface)
6976
7032
  ```typescript
6977
7033
  interface ProofCreateRequest {
6978
- values: Record<string, any>
7034
+ values: ProofValues
7035
+ data?: Record<string, JsonValue>
7036
+ admin?: Record<string, JsonValue>
6979
7037
  claimable?: boolean
6980
7038
  virtual?: boolean
6981
7039
  }
6982
7040
  ```
6983
7041
 
7042
+ **ProofFieldsConfig** (interface)
7043
+ ```typescript
7044
+ interface ProofFieldsConfig {
7045
+ fields: ProofFieldDef[]
7046
+ }
7047
+ ```
7048
+
6984
7049
  **ProofResponse** = `Proof`
6985
7050
 
6986
7051
  **ProofUpdateRequest** = `Partial<ProofCreateRequest>`
6987
7052
 
6988
7053
  **ProofClaimRequest** = `Record<string, any>`
6989
7054
 
7055
+ **ProofFieldScope** = `'public' | 'owner' | 'personal' | 'admin'`
7056
+
7057
+ **ProofFieldDef** = `ScopedFieldDef & { scope?: ProofFieldScope }`
7058
+
6990
7059
  ### qr
6991
7060
 
6992
7061
  **QrShortCodeLookupResponse** (interface)
package/dist/docs/ai.md CHANGED
@@ -251,6 +251,100 @@ const response = await ai.chat.responses.create('my-collection', {
251
251
  console.log(response.output);
252
252
  ```
253
253
 
254
+ ### Recommended Models
255
+
256
+ For agentic workflows on `v1/responses`, GPT-5.6 ships in three tiers. Pass either the full model
257
+ id (`openai/gpt-5.6-sol`) or the shorthand tier alias (`'cheap'`, `'balanced'`, `'premium'`) as
258
+ `model` — both resolve through the same server-side model registry.
259
+
260
+ | Tier | Model | Alias | Use for |
261
+ |------|-------|-------|---------|
262
+ | Cheapest (default) | `openai/gpt-5.6-luna` | `'cheap'` / omit `model` | Everyday chat, high-volume/simple turns |
263
+ | Balanced | `openai/gpt-5.6-terra` | `'balanced'` | Admin agent / tool-heavy setup workflows (route default) |
264
+ | Flagship | `openai/gpt-5.6-sol` | `'premium'` | Most demanding reasoning, coding, and multi-step tool use |
265
+
266
+ Every tier supports function/tool calling, Programmatic Tool Calling, and Multi-agent (see below), and all
267
+ three accept `service_tier: 'flex'` (≈50% cheaper, Batch-API rates, slower) or `'priority'` (premium, guaranteed
268
+ throughput) alongside the default `'standard'` tier. Pass it straight through in the request body:
269
+
270
+ ```typescript
271
+ const response = await ai.chat.responses.create('my-collection', {
272
+ model: 'balanced',
273
+ input: 'Summarize this week\'s ingested documents.',
274
+ service_tier: 'flex' // non-interactive/background work: cheaper, but can take minutes
275
+ });
276
+ ```
277
+
278
+ Flex requests run noticeably slower — reserve `flex` for non-production/background work (batch enrichment,
279
+ evaluations, async jobs), not user-facing chat turns. The server already raises its own timeout to 15
280
+ minutes for any request with `service_tier: 'flex'`, matching OpenAI's guidance — nothing to configure on
281
+ the client. On a `429` ("resource unavailable") the request wasn't charged; retry with backoff or drop
282
+ `service_tier` (or set it to `'auto'`) to fall back to standard processing.
283
+
284
+ ### Programmatic Tool Calling
285
+
286
+ Lets the model write a short in-memory program that orchestrates several tool calls (filtering,
287
+ looping, aggregating) before handing back one result, instead of a full message round-trip per
288
+ call. Add the hosted `programmatic_tool_calling` tool, and mark each function tool the program is
289
+ allowed to invoke with `allowed_callers: ['programmatic']`:
290
+
291
+ ```typescript
292
+ const response = await ai.chat.responses.create('my-collection', {
293
+ model: 'balanced',
294
+ input: 'Compare inventory with demand for every SKU in this collection.',
295
+ tools: [
296
+ {
297
+ type: 'function',
298
+ name: 'get_inventory',
299
+ description: 'Return available_units for a sku',
300
+ parameters: { type: 'object', properties: { sku: { type: 'string' } }, required: ['sku'] },
301
+ output_schema: { type: 'object', properties: { sku: { type: 'string' }, available_units: { type: 'number' } } },
302
+ allowed_callers: ['programmatic']
303
+ },
304
+ {
305
+ type: 'function',
306
+ name: 'get_demand',
307
+ description: 'Return requested_units for a sku',
308
+ parameters: { type: 'object', properties: { sku: { type: 'string' } }, required: ['sku'] },
309
+ output_schema: { type: 'object', properties: { sku: { type: 'string' }, requested_units: { type: 'number' } } },
310
+ allowed_callers: ['programmatic']
311
+ },
312
+ { type: 'programmatic_tool_calling' }
313
+ ]
314
+ });
315
+ ```
316
+
317
+ The response's `output` array can include a `program` item (the generated code), one
318
+ `function_call` item per program-issued call (tagged with `caller: { type: 'program', caller_id }`),
319
+ and a `program_output` item with the program's final `result`/`status`. Execute the `function_call`
320
+ items as normal and send results back keyed by their `call_id` on the next turn.
321
+
322
+ ### Multi-agent (subagents)
323
+
324
+ Lets the root agent spawn a tree of subagents that run in parallel and get synthesized back into
325
+ one response — useful for tasks that split cleanly into independent workstreams (e.g. research +
326
+ draft + review). Enable it by setting `multi_agent.enabled: true` — that's the entire contract on
327
+ your end; nothing else to configure or pass.
328
+
329
+ This is upstream beta functionality (OpenAI may still be limiting it to certain accounts/rollout),
330
+ so treat behavior and availability as subject to change until it's GA.
331
+
332
+ ```typescript
333
+ const response = await ai.chat.responses.create('my-collection', {
334
+ model: 'premium', // Sol recommended for the root agent when spawning subagents
335
+ input: 'Research three competitor loyalty programs, then draft a comparison summary.',
336
+ multi_agent: { enabled: true, max_concurrent_subagents: 3 }
337
+ });
338
+ ```
339
+
340
+ Subagent output arrives as additional items in `output`, each tagged `agent: { agent_name: '/root/<name>' }`
341
+ (root agent output uses `/root`). Notes/limits carried over from OpenAI's beta:
342
+
343
+ - `max_concurrent_subagents` defaults to `3`
344
+ - `reasoning.summary` and `max_tool_calls` are not supported while multi-agent is enabled
345
+ - Streaming is not supported while multi-agent is enabled — the SDK throws if you pass both
346
+ `stream: true` and `multi_agent.enabled: true`
347
+
254
348
  ---
255
349
 
256
350
  ## Chat Completions
@@ -2,6 +2,8 @@
2
2
 
3
3
  The SmartLinks platform provides two distinct types of data storage for apps:
4
4
 
5
+ > **Not what you're looking for?** This guide covers app-owned config/records scoped to a collection or product. For the core product/proof documents themselves — `product.data`/`.admin`, `proof.data`/`.admin`/`.values` (owner/personal) — see [proof-product-data-scoping.md](proof-product-data-scoping.md).
6
+
5
7
  ## Choose the Right Model First
6
8
 
7
9
  There are now two different families of flexible app data in SmartLinks, and they solve different problems:
@@ -80,6 +80,7 @@ The SmartLinks SDK (`@proveanything/smartlinks`) includes comprehensive document
80
80
  | **Contact Search** | `docs/contact-search.md` | Admin contact search: free-text, typeahead, identity/tag/JSONB filters, and pagination |
81
81
  | **App Records Pattern** | `docs/app-records-pattern.md` | Standard pattern for per-product/facet/variant/batch admin + public widget UIs |
82
82
  | **UI Utils** | `docs/ui-utils.md` | `@proveanything/smartlinks-utils-ui` — React shells, hooks, and primitives for records-based apps |
83
+ | **Product/Proof Data Scoping** | `docs/proof-product-data-scoping.md` | Canonical spec for `product.data`/`.admin` and `proof.data`/`.admin`/`.values` (owner/personal) — who can read and write each bucket |
83
84
 
84
85
  ---
85
86
 
@@ -204,6 +205,12 @@ Prefer `app.records` over `setDataItem` when the data is becoming a real entity
204
205
 
205
206
  For data attached to specific proof instances, use `SL.attestation.create()` and `SL.attestation.list()`.
206
207
 
208
+ ### Custom Data Scoping (Product & Proof)
209
+
210
+ `product.data`/`product.admin` and `proof.data`/`proof.admin`/`proof.values` are the canonical buckets for custom fields on products and proofs — `data` is public and business-writable, `admin` is business-only, and `proof.values` additionally supports owner-scoped (`values.owner`) and per-user (`values.personal[userId]`) sub-keys. This is a different mechanism from the app-scoped storage in `docs/app-data-storage.md` (which is for app-owned config/records, not the product/proof documents themselves).
211
+
212
+ See `docs/proof-product-data-scoping.md` for the full read/write authority matrix, worked examples, and the `productFields`/`proofFields` collection-settings schemas that drive field-config editors.
213
+
207
214
  ---
208
215
 
209
216
  ## Error Handling