Verify API key - Verify that your API key is valid and check rate limit status.

Use when: at the start of any session or batch job, to confirm the API key is valid and the site is reachable BEFORE burning rate limit on real calls. Also useful for surfacing a clear "bad credentials" error to the user early.

Parameter interactions:

• Call at the start of a session to confirm the API key is valid BEFORE issuing real calls - saves rate-limit budget on key-config errors

Returns: { status: "success"|"error", message: ... } - BD's standard response envelope.

Get user field definitions - Returns available fields for user records with labels and required flags. Use this to discover custom fields.

Use when: building dynamic forms or importers - you need to discover which fields exist on the User record on THIS specific site (custom fields vary per BD site config). Also useful for validating import-CSV headers before running a batch.

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

List members/users - Get a paginated list of all members. Supports filtering by any user field and sorting.

Lean-by-default keep-list: rows return only identity + routing + location core: user_id, first_name, last_name, email, company, phone_number, subscription_id, profession_id, active, status, city, state_code, country_code, filename, image_main_file, signup_date, last_login, modtime. Everything else stripped — restore via flags: include_password=1, include_subscription=1 (full subscription_schema), include_clicks=1 (full click array), include_photos=1 (full photos_schema), include_transactions=1, include_profession=1 (profession_schema), include_tags=1, include_services=1 (services_schema), include_seo_hidden=1, include_about=1 (about_me HTML bio), include_legacy_fields=1 (image-import state on photos, requires include_photos), include_extras=1 (everything else — billing/analytics rollups like revenue/card_info/total_clicks/total_photos, duplicate location fields state_ln/country_ln/full_name/user_location/zip_code/lat/lon, plus social URLs, awards, credentials, position, quote, work_experience, rep_matters, cv, gmap, no_geo, user_consent, sign_up_origin, listing_type, profession_name, ref_code, booking_link, bitly, cookie, token, verified, featured, parent_id, clientid, etc.).

Use when: enumerating members for reports, CSV exports, bulk status updates, analytics, or pagination through the full member base. Also used for lookups by field - pass property=email + property_value=<email> to find a single user by email. For keyword/text search use searchUsers; for a single user by known user_id use getUser. Do NOT bulk-list users to enumerate cities the site has on file — use listCities (lean, BD-curated, surfaces only cities where members exist).

Pagination: cursor-based. Pass limit (default 25, max 100) and page token from the previous response's next_page. Do not assume integer offsets.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

Enums: property_operator: =, LIKE, >, <, >=, <=; order_type: ASC, DESC.

Filter-property rule - use ACTUAL field names: property must reference a real column on users_data or a valid custom user field. If you don't know what's filterable, call getUserFields first - it returns the authoritative list for this site (includes custom fields). BD returns misleading errors like "user not found" when property names a nonexistent field - that is a BAD FILTER, not a 404 on the endpoint. Do not invent properties like user_group (not a real column).

Filtering by TOP CATEGORY (profession): the filter column is profession_id (integer), not a category name string. If the caller gives you a category name, chain: (1) listTopCategories -> find the row whose name matches; (2) grab its profession_id; (3) call listUsers with property=profession_id&property_value=<id>. Same principle for any taxonomy filter - resolve names to IDs first via listSubCategories, listMembershipPlans, etc. For sub-category filtering on users, the authoritative approach is listMemberSubCategoryLinks filtered by service_id -> collect user_ids -> fetch those users. (There is also a service CSV column on user records but exact-match filtering on it requires the complete CSV value and LIKE syntax support is not guaranteed - prefer the link-table route.)

Filtering by users_meta (custom/meta fields): multi-value meta filtering IS supported via the array syntax - e.g. property[]=<meta_key>&property_value[]=foo&property[]=<meta_key>&property_value[]=bar&property_operator[]=OR&property_logic[]==. Use this for OR-across-meta-values lookups (e.g. members whose custom field equals any of N options).

Payment-method field (under include_extras=1): card_info is false when no card is on file (BD's convention), or an object with last4/brand/name when a card IS stored. Check card_info && card_info.last4 (truthy-guard). Authoritative signal for "does this member have a valid payment method on file" — do not infer from subscription_id alone.

See also: getUser (single record by ID), searchUsers (keyword search), getUserFields (list filterable fields).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is lean-shaped per the keep-list above.

Profile URL: every user record has a filename field. To get the full public profile URL, concatenate: <site-domain>/<user.filename>. The filename is the complete relative path (e.g., united-states/monterey-park/doctor/harrison-hasanuddin-d-o) - DO NOT prepend /business/, /profile/, /member/, or any other segment. BD's router resolves filename verbatim.

Get a single member/user - Fetch a single user record. Read-only.

Lean-by-default keep-list: same shape as listUsers — identity + routing + location core (user_id, first_name, last_name, email, company, phone_number, subscription_id, profession_id, active, status, city, state_code, country_code, filename, image_main_file, signup_date, last_login, modtime). Restore extras via flags: include_password=1, include_subscription=1, include_clicks=1, include_photos=1, include_transactions=1, include_profession=1, include_tags=1, include_services=1, include_seo_hidden=1, include_about=1, include_legacy_fields=1, include_extras=1 (billing/analytics rollups revenue/card_info/total_clicks/total_photos, duplicate location fields state_ln/country_ln/full_name/user_location/zip_code/lat/lon, plus social URLs, awards, credentials, position, quote, work_experience, ref_code, booking_link, etc.).

Use when: you already have the user_id (from listUsers, searchUsers, a prior create, or a webhook payload) and need the full member record. Cheaper than listUsers + filter. For lookups by email or other field, use listUsers with property/property_value.

Required: user_id.

See also: listUsers (enumerate many), searchUsers (keyword search).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 lean-shaped record when found. Empty or HTTP 404 when not found.

Payment method on file (under include_extras=1): card_info is false when no card is stored (BD convention), or an object with last4/brand/name when one is. Use card_info && card_info.last4 to safely check. Authoritative signal for "does this member have a payment method" — don't infer from subscription_id alone.

Profile URL: every user record has a filename field. To get the full public profile URL, concatenate: <site-domain>/<user.filename>. The filename is the complete relative path (e.g., united-states/monterey-park/doctor/harrison-hasanuddin-d-o) - DO NOT prepend /business/, /profile/, /member/, or any other segment. BD's router resolves filename verbatim. Note: filename is regenerated by BD when member inputs that influence the slug change (category, city, etc.). The value you see NOW is current-as-of-this-read. If you call updateUser afterward, re-fetch before using the filename in URL-referencing content (blog posts, emails, redirects).

Create a new member/user - Create a member. Writes live data. Welcome email silent by default - set send_email_notifications=1 to trigger.

Required: email, password, subscription_id.

Use when: adding members outside BD signup - CSV imports, scraped listings, Zapier automations, admin test accounts.

Enums: active: 1=Not Active, 2=Active, 3=Canceled, 4=On Hold, 5=Past Due, 6=Incomplete. listing_type: Individual, Company. verified/nationwide: 1/0.

Prerequisites: subscription_id MUST reference an existing plan - discover via listMembershipPlans. For category assignment via profession_id / profession_name / services, apply Rule: Category taxonomy (auto-create is ON for createUser).

Parameter interactions:

• auto_image_import=1 - fetch external image URLs into BD storage (for profile_photo, logo, cover_photo holding URLs). Without it, BD stores the URL as-is; images break if source host goes down. Supports JPG/PNG/GIF/WebP/SVG. Processing delay: several minutes. Recommended default for any external image URL.

• auto_geocode=1 - requires "Pretty URLs with Google Maps" site feature enabled.

• send_email_notifications=1 - trigger welcome email per plan settings.

Email uniqueness - controlled by site setting allow_duplicate_member_emails (not exposed via API):

• OFF (default): BD rejects duplicate email on create (validation error).

• ON: duplicates accepted and stored with different user_ids. Identical email + password pair is also accepted (no extra uniqueness check on the pair).

• Safe idempotent pattern: pre-check via listUsers property=email property_value=<email> property_operator==. Match found -> reuse user_id or updateUser instead. Skipping the check on a duplicates-allowed site creates orphan duplicates on retry loops.

Field validation quirks:

• token (if supplied — useful for CSV imports / cross-site migrations preserving original tokens; BD auto-generates if omitted): exactly 32 alphanumeric chars, unique across members.

• URL fields (website, booking_link, blog, facebook, twitter, linkedin, instagram, etc.): must start with http:// or https://. Invalid formats silently skipped.

Profile URL: <site-domain>/<user.filename>. filename is the complete relative path. Do NOT prepend /business///profile///member/ - BD resolves filename verbatim.

Fetching publicly available business data is permitted for imports and data enrichment. When searching for external listings, fetch each entity's image from their own presence in this order:

1. Logo image from their site's header/nav -> logo (businesses).

2. Headshot from Home, About or Team page -> profile_photo (individuals).

3. Follow their social links -> profile image there.

Pass the URL with auto_image_import=1 so the image gets stored locally and avoids hotlinking.

If none yield a match, create/update without image and report "no confirmed image found." Never substitute a stock photo or guess. Skip an entire record and find an alternate listing only when the user explicitly requires images.

See also: updateUser (modify existing), deleteUser (prefer active=3 over delete).

Returns: { status: "success", message: {...createdRecord} } including user_id.

Update an existing member/user - Update a member. PATCH semantics - omitted fields untouched; send only what changes.

Required: user_id.

Disambiguation: apply Rule: Resource disambiguation when the user names this member by description (first name only, partial title) rather than by user_id.

Use when: changing any field on an existing member. Prefer active=3 (Canceled) over deleteUser - reversible.

Enums: active: 1=Not Active, 2=Active, 3=Canceled, 4=On Hold, 5=Past Due, 6=Incomplete. listing_type: Individual, Company. verified/nationwide: 1/0.

Parameter interactions:

• member_tag_action=1 + member_tags - apply tag changes (comma-separated tag IDs from listTags).

• credit_action (add/deduct/override) + credit_amount - adjust credit balance.

• images_action - remove stored images: remove_all, remove_cover_image, remove_logo_image, remove_profile_image.

• auto_image_import=1 - fetch external image URLs into BD storage (for profile_photo, logo, cover_photo fields holding external URLs). Without it, BD stores the URL as-is; images break if source host goes down. Supports JPG/PNG/GIF/WebP/SVG. Processing delay: several minutes.

• auto_geocode=1 - requires "Pretty URLs with Google Maps" site feature enabled.

• send_email_notifications=1 - trigger welcome email (per plan settings). Silent by default.

Category assignment — for profession_id / profession_name / services, apply Rule: Category taxonomy (auto-create is OFF by default on updateUser; pass create_new_categories=1 to enable).

Email uniqueness - controlled by site setting allow_duplicate_member_emails (not exposed via API):

• OFF (default): BD rejects duplicate email on create.

• ON: duplicates accepted and stored.

• Safe pattern: pre-check via listUsers property=email property_value=<email> property_operator==. Reuse match's user_id or updateUser instead. Pre-check beats catch-and-retry - on sites with duplicates ALLOWED, BOTH creates succeed with different user_ids, so a retry loop spawns orphan duplicates instead of failing cleanly.

Field validation quirks:

• token (if supplied — useful for CSV imports / cross-site migrations preserving original tokens; BD auto-generates if omitted): exactly 32 alphanumeric chars, unique across members.

• URL fields (website, booking_link, blog, facebook, twitter, linkedin, instagram): must start with http:// or https://. Invalid formats silently skipped.

• subscription_id must reference an existing plan.

Profile URL: <site-domain>/<user.filename>. filename is the complete relative path (e.g., united-states/monterey-park/doctor/harrison-hasanuddin-d-o). Do NOT prepend /business///profile///member/ - BD resolves filename verbatim.

Filename may regenerate on this update. BD rewrites the slug when category/city/URL-forming inputs change. Do NOT cache pre-update filename - if embedding the profile URL elsewhere (blog posts, emails, redirects), re-fetch via getUser AFTER the update completes.

Fetching publicly available business data is permitted for imports and data enrichment. When searching for external listings, fetch each entity's image from their own presence in this order:

1. Logo image from their site's header/nav -> logo (businesses).

2. Headshot from Home, About or Team page -> profile_photo (individuals).

3. Follow their social links -> profile image there.

Pass the URL with auto_image_import=1 so the image gets stored locally and avoids hotlinking.

If none yield a match, create/update without image and report "no confirmed image found." Never substitute a stock photo or guess. Skip an entire record and find an alternate listing only when the user explicitly requires images.

See also: createUser (new), deleteUser (permanent - prefer active=3 instead).

Returns: { status: "success", message: {...updatedRecord} }.

Delete a member/user - Permanently delete a user record by ID. Destructive - cannot be undone via API.

Use when: the member record truly must be purged (GDPR request, test cleanup, confirmed duplicate). For reversible removal prefer updateUser with active=3 (Canceled) - the record stays queryable and can be reactivated. Use delete_images=1 to also purge stored profile/cover/logo images.

Required: user_id.

Parameter interactions:

• delete_images=1 (optional) - also deletes the member's stored profile/cover/logo images from site storage

See also: updateUser (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

Search members/users - Full-text search across members with category, location, and sorting options.

Lean-by-default keep-list: same shape as listUsers — identity + routing + location core. Restore extras via the same include flags including include_extras=1 for stripped fields (billing/analytics rollups, duplicate location fields, social URLs, awards, credentials, work_experience, etc.).

Use when: (1) mirroring the public member-search experience - embedding search results in an external app, building a custom search-results page, or letting users search BD from outside the site; (2) verifying what is publicly findable for a given keyword / category / location combo (SEO coverage audits, "who shows up if a visitor searches X?"); (3) keyword / partial-name / location / category lookup in general. For exact-field lookup (by email, by user_id, by phone, by any admin column) use listUsers + property / property_value - faster, more precise, and supports admin-only filters (join date, subscription status, meta fields) that this endpoint does not.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Enums: sort: reviews, name ASC, name DESC, last_name_asc, last_name_desc.

Parameter interactions:

• q - keyword (matches first name, last name, company, about, search_description)

• pid (category ID), tid (sub-category/service ID), ttid (sub-sub-category) - taxonomy filters, use IDs from listTopCategories / listSubCategories

• address + dynamic=1 - proximity/geographic filtering

See also: getUser (single record by ID), listUsers (full enumeration).

Returns: { status: "success", message: [...records] }. Supports pagination fields when result set is large.

Profile URL: every user record has a filename field. To get the full public profile URL, concatenate: <site-domain>/<user.filename>. The filename is the complete relative path (e.g., united-states/monterey-park/doctor/harrison-hasanuddin-d-o) - DO NOT prepend /business/, /profile/, /member/, or any other segment. BD's router resolves filename verbatim.

Validate user credentials - Checks if email/password are valid. Does NOT return profile data - use getUser after.

Use when: implementing SSO or a custom login flow against BD - you need to verify a member's email+password is valid WITHOUT starting a web session. Does NOT return profile data; follow with getUser or listUsers to fetch the authenticated member's record.

Required: email, password.

Parameter interactions:

• Does NOT return profile data on success - follow with getUser using the verified email to retrieve the member record

Returns: { status: "success"|"error", message: ... } - BD's standard response envelope.

Get member billing transactions (invoices) - Fetch the billing transaction history (invoices) for a specific member. Read-only. Backed by the WHMCS billing integration.

Required: exactly one of user_id (standard — the BD member ID) OR client_id (power-user — the WHMCS billing record ID stored on the user as users_data.clientid). Default to user_id; reach for client_id only when you already have one in hand and want to bypass the user lookup.

Empty result with misleading error: if the member has no billing record yet (never enrolled in any paid plan), BD returns HTTP 400 + {status:"error", message:"user_id or client_id is required"} even though the identifier WAS sent. The error wording is BD's, not the wrapper's. Treat that exact error message on this endpoint as "no billing data for this member" rather than "missing parameter".

Use when: you need to see a member's paid/unpaid invoices, payment methods, billing history, or reconcile billing status. Common reasons: answering a member's "what did I pay for?" question, exporting billing history, auditing revenue per member.

See also: getUserSubscriptions (active/past membership plan signups - different resource from invoices), getUser (member profile).

Returns: { status: "success", message: { total: <count>, invoices: [{...invoice records}] } }. Each invoice includes id, invoicenum (may be empty string), date, duedate, datepaid, subtotal, credit, tax, total, status (Paid, Unpaid, etc.), paymentmethod, notes (admin-facing; may contain internal comments - redact before surfacing to end users), and an items array with per-line description, amount, type. NOT a simple list of rows - the message is an object containing invoices as the array. Unpaid invoices have datepaid: "0000-00-00 00:00:00" (MariaDB zero-date sentinel) - do NOT parse as ISO-8601; check status === 'Unpaid' or datepaid.startsWith('0000') first. subscription_details may be false (literal boolean) when absent.

Reference support articles:

Get member subscriptions (membership plan history) - Fetch the subscription / membership-plan history for a specific member. Read-only. Backed by the WHMCS billing integration.

Required: exactly one of user_id (standard — the BD member ID) OR client_id (power-user — the WHMCS billing record ID stored on the user as users_data.clientid). Default to user_id; reach for client_id only when you already have one in hand and want to bypass the user lookup.

Empty result with misleading error: if the member has no billing record yet (never enrolled in any paid plan), BD returns HTTP 400 + {status:"error", message:"user_id or client_id is required"} even though the identifier WAS sent. The error wording is BD's, not the wrapper's. Treat that exact error message on this endpoint as "no billing data for this member" rather than "missing parameter".

Use when: checking a member's current membership plan, their billing cycle (Monthly/Yearly), next due date, plan upgrade history, whether auto-renewal is on, or past canceled subscriptions.

See also: getUserTransactions (invoice-level billing records - different resource), getUser (member profile - profile-level subscription references subscription_id), listMembershipPlans (all plan definitions on the site).

Returns: { status: "success", message: { total: <count>, subscriptions: [{...subscription records}] } }. Each subscription includes id, userid, packageid (membership plan ID), regdate, nextduedate, billingcycle (e.g. Monthly, Yearly), paymentmethod, amount, domainstatus (Active, Cancelled, etc.), and related fields. NOT a simple list of rows - the message is an object containing subscriptions as the array.

Reference support articles:

List reviews - Paginated enumeration of review records. Read-only.

Lean by default: review_description is truncated to the first 500 chars + … when longer. Truncated rows are tagged review_description_truncated: true. Pass include_full_text=1 to restore the full body per call (use sparingly at high limit — review text is unbounded and can dominate payload).

Use when: building moderation queues (filter review_status=0 for Pending), exporting all reviews, running review-velocity reports, or paginating through every review on the site. For keyword-in-body matching, use property=review_description property_operator=LIKE property_value=<word>. For a single known review use getReview.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

Enums: property_operator: =, LIKE, >, <, >=, <=.

See also: getReview (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the full resource object (with review_description truncated by default; see Rule: Lean read responses).

Get a single review - Fetch a single review record. Read-only.

Lean by default: review_description is truncated to the first 500 chars + … when longer (tagged review_description_truncated: true). Pass include_full_text=1 to get the complete body. For a single-record inspection this is usually the right call.

Use when: investigating one specific review (usually from a moderation notification or support ticket that includes the review_id). For bulk moderation use listReviews with review_status filter.

Required: review_id.

See also: listReviews (enumerate many; supports keyword filter via property=review_description property_operator=LIKE).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Create a review - Create a new review record. Writes live data.

Use when: importing legacy reviews from another platform, adding placeholder reviews for test data, or scripting review submissions from an external integration. Real member-submitted reviews come through the BD review form - only use this API when bypassing that form.

Required: user_id, review_email.

Parameter interactions:

• user_id - the member being reviewed

• rating_overall: integer 1-5 (higher = better)

• recommend: 0=No, 1=Yes (shown as a thumbs-up recommendation flag)

• review_status controls initial visibility - default flow is 0 Pending -> admin review

See also: updateReview (modify existing).

Update a review - Update an existing review record by ID. Fields omitted are untouched. Writes live data.

Use when: moderating - change review_status (0=Pending -> 2=Accepted to publish, 3=Declined to reject, 4=Waiting for Admin). Also used for admin corrections of typos in review text.

Required: review_id.

Enums: review_status: 0=Pending, 2=Accepted, 3=Declined, 4=Waiting for Admin.

See also: createReview (add new), deleteReview (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete a review - Permanently delete a review record by ID. Destructive - cannot be undone via API.

Use when: the review content violates policy and must be purged (spam, abuse, PII). For "hide without removing" use updateReview with review_status=3 (Declined) - preserves the audit trail.

Required: review_id.

See also: updateReview (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List click records - Paginated enumeration of click records. Read-only.

Use when: pulling click-tracking analytics for reports - profile views, phone reveals, website clicks, email clicks. Filter by user_id to see clicks for one member.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getClick (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the full resource object.

Get a single click record - Fetch a single click record. Read-only.

Use when: rare - drilling into a specific click record by click_id. Most click-analytics work happens via listClicks with filters.

Required: click_id.

See also: listClicks (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Create a click record - Create a new click record. Writes live data.

Use when: replicating a click event from an external source (e.g., tracking clicks on a mirrored profile page on another domain). Usually not needed - BD auto-records clicks on its own surfaces.

Required: user_id, click_type, click_name, click_from, click_url.

Parameter interactions:

• user_id - the member profile being tracked

• click_type - link (external), phone (reveal), or email (reveal)

• click_from - source surface: profile_page or search_results

• click_url - the URL that was clicked

See also: updateClick (modify existing).

Update a click record - Update an existing click record by ID. Fields omitted are untouched. Writes live data.

Use when: correcting click metadata. Rare - click records are typically append-only analytics.

Required: click_id.

See also: createClick (add new), deleteClick (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete a click record - Permanently delete a click record by ID. Destructive - cannot be undone via API.

Use when: removing test or spam click records from analytics. Does NOT affect the member's click counter if the site displays one.

Required: click_id.

See also: updateClick (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List leads - Paginated enumeration of lead records. Read-only.

Use when: pulling the admin's lead inbox, generating lead reports, or iterating all leads to push into a CRM. For fetching one lead by ID use getLead.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getLead (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the full resource object.

Get a single lead - Fetch a single lead record. Read-only.

Use when: handling one lead - viewing its details after a lead-notification email, following up in a CRM integration, or confirming the lead exists before calling matchLead.

Required: lead_id.

See also: listLeads (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Create a lead - Create a new lead record. Writes live data.

Use when: importing leads from an external form, CSV, or web-scrape. Default is SILENT - no notification emails fire unless you pass send_lead_email_notification=1, and no member routing happens unless you pass auto_match=1 (inline) or call matchLead afterward. top_id (category) is required - look it up via listTopCategories.

Required: lead_name, lead_email, lead_phone, lead_message, lead_location, top_id.

Parameter interactions:

• top_id - category ID; discover via listTopCategories

• All 6 required fields (lead_name, lead_email, lead_phone, lead_message, lead_location, top_id) must be supplied together

• Response includes lead_id AND token - token may be needed for customer-facing URLs

• After creating, call matchLead to trigger member notifications

See also: updateLead (modify existing).

Operational rules (from BD support article 12000091106):

• send_lead_email_notification=1 - activates lead email notifications to the site admin and/or matched members. Default is off: leads created via API are silent unless this flag is set. For the full auto-matching flow (finds members by category/location and emails them), call matchLead separately after creating the lead (or pass auto_match=1 on this call to run inline).

Targeting specific members (override auto-match): set users_to_match to a comma-separated list of member IDs or emails (e.g. 6099,6100 or user1@example.com,user2@example.com, mixed OK). This BYPASSES the normal category/location/service-area matching and routes the lead to ONLY those members. Typically paired with auto_match=1 (to run the match step inline) and send_lead_email_notification=1 (to fire the matched-member email). Common pattern when an external system already knows who should receive the lead.

Auto-match lead to members - Triggers automatic matching - system finds members matching category, location, and service area, then sends notification emails.

Use when: you've just created a lead (or need to re-distribute an existing one) and want BD to automatically email eligible members in matching category + location + service area. SIDE EFFECT: sends real emails to real members. Confirm with the user before calling on production data.

Required: lead_id.

Parameter interactions:

• Side effect: sends notification emails to ALL members whose category, location, and service area match the lead

• Not a dry-run - emails go out immediately. Not rate-limited per lead

• lead_id must reference an existing lead created via createLead

Returns: { status: "success"|"error", message: ... } - BD's standard response envelope.

Update a lead - Update an existing lead record by ID. Fields omitted are untouched.

Required: lead_id.

Custom (form-defined) lead fields — e.g. wizard-style hidden match_* fields — live in users_meta with database=leads and database_id=<lead_id>. Use updateUserMeta / createUserMeta for those. Rule: Forms § Form classes → Custom-field storage covers the pattern.

See also: createLead, deleteLead, matchLead, updateUserMeta.

Returns: { status: "success", message: {...updatedRecord} }.

Delete a lead - Permanently delete a lead record by ID. Destructive - cannot be undone via API.

Use when: removing a spam or test lead. For preserving the lead but closing it, use updateLead with a status change instead.

Required: lead_id.

See also: updateLead (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List lead matches - Paginated enumeration of lead_matches records. Read-only.

Use when: auditing who got notified about which lead - useful for billing reports (paid-per-lead sites) or explaining to a member why they did/didn't receive a lead notification. Filter by lead_id to see all matches for one lead, or by user_id to see all leads a member received.

Empty-state quirk: BD returns { status: "error", message: "lead_matches not found", total: 0 } on zero rows (NOT the standard success-shape). The wrapper normalizes this to { status: "success", total: 0, message: [] } before responding — but if a raw BD response leaks through, treat the exact message "lead_matches not found" as an empty result, not as an endpoint failure.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }.

Get a single lead match - Fetch a single leadmatch record. Read-only.

Use when: you have a specific match_id (from listLeadMatches) and need the full match row - lead points, price, response status, etc.

Required: match_id.

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Create a lead match - Create a new leadmatch record. Writes live data.

Use when: manually creating a lead↔member match BYPASSING BD's auto-matching. Rarely needed - usually matchLead handles this automatically. Use for data migrations, manual override scenarios, or replaying matches from another system.

Required: lead_id, user_id, lead_status, match_price, lead_token, lead_matched_by.

Pre-check before create (PAIR uniqueness): BD does NOT enforce uniqueness on the (lead_id, user_id) pair. Matching the same lead to the same member twice creates two match rows - the member gets double-billed (if the match charges credits), both rows appear in the member's inbox, and reporting double-counts the match. Filter-find pattern (single-field server filter + client-side intersect - the server does not yet honor array-syntax multi-condition filters): call listLeadMatches property=lead_id property_value=<proposed lead_id> property_operator== to narrow to all matches for that lead, then CLIENT-SIDE filter the returned rows to those where user_id=<proposed user_id>. Zero results after the client-side step = pair free; >=1 = already matched. If the pair already exists: reuse via updateLeadMatch (e.g. to bump lead_status), OR confirm with the user before creating the duplicate match. Never silently double-match.

Parameter interactions:

• Usually created automatically by matchLead; manual creation bypasses BD's matching logic

• lead_id and user_id must both exist (use getLead / getUser to verify)

• lead_status - match lifecycle state (see Enums)

• match_price, lead_points, lead_rating, lead_distance - scoring fields used in ranking and billing

See also: updateLeadMatch (modify existing).

Update a lead match - Update an existing leadmatch record by ID. Fields omitted are untouched. Writes live data.

Use when: recording a member's response to a lead (lead_response, lead_accepted, lead_chosen) or adjusting lead_points/match_price for billing reconciliation.

Required: match_id.

Enums: lead_status: 1=Pending, 2=Matched, 4=Follow-Up, 5=Sold Out, 6=Closed, 7=Bad Leads, 8=Delete. (Verified against admin UI dropdown 2026-04-19. Value 3 does not exist. BD accepts out-of-range integers silently - stick to this set.)

See also: createLeadMatch (add new), deleteLeadMatch (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete a lead match - Permanently delete a leadmatch record by ID. Destructive - cannot be undone via API.

Use when: cleaning up an erroneous match (e.g., test data) or removing a match that was auto-created but shouldn't exist. Does NOT unsend the notification email that may have already fired.

Required: match_id.

See also: updateLeadMatch (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List posts - Paginated enumeration of post records. Read-only.

Lean-by-default keep-list: rows return only the core identity + routing + load-bearing fields: post_id, post_title, post_filename, post_status, post_start_date, post_expire_date, post_location, post_venue, post_category, data_id, data_type, system_name, data_name, data_filename, user_id, post_image, original_image_url, revision_timestamp, plus total_clicks (only when > 0) / total_photos rollups. Everything else stripped — restore via flags:

• include_content=1 - return post_content (HTML body).

• include_post_seo=1 - return post_meta_title, post_meta_description, post_meta_keywords.

• include_author_full=1 - return the full user nested object. Default omits author detail entirely; call getUser(user_id) for author records.

• include_clicks=1 - return the full click array under user_clicks_schema.

• include_photos=1 - return the full users_portfolio photo array (multi-image posts).

• include_extras=1 - return everything else (lat, lon, country_sn, state_sn, post_org_url, post_date, post_live_date, post_updated, post_token, post_clicks, recurring_type, sticky_post, post_featured, post_tags, post_job, post_video, post_price, image_imported, etc.).

Use when: enumerating posts of single-image families - blog articles, events, jobs, coupons, videos, discussions. Filter by user_id for one member's posts, or data_id to scope to one post type. Before using, confirm the target post type has data_type 9 or 20 (single-image); data_type=4 means multi-image and you want listMultiImagePosts instead.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getSingleImagePost (single record by ID). For keyword-in-body matching, use this tool with property=post_title property_operator=LIKE (or post_caption/post_content).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the lean-shaped resource object.

Get a single post - Fetch a single post record. Read-only.

Lean-by-default keep-list: response returns only the core identity + routing + load-bearing fields: post_id, post_title, post_filename, post_status, post_start_date, post_expire_date, post_location, post_venue, post_category, data_id, data_type, system_name, data_name, data_filename, user_id, post_image, original_image_url, revision_timestamp, plus total_clicks (only when > 0) / total_photos rollups. Same shape as listSingleImagePosts. Restore via flags: include_content=1 (full post_content HTML), include_post_seo=1 (meta_title/description/keywords), include_author_full=1 (full user nested — default omits author detail; call getUser(user_id) otherwise), include_clicks=1 (click array), include_photos=1 (photo array on multi-image), include_extras=1 (everything else: lat, lon, country_sn, state_sn, post_org_url, post_date, post_live_date, post_updated, post_token, post_clicks, recurring_type, sticky_post, post_featured, post_tags, post_job, post_video, post_price, image_imported, etc.).

Use when: fetching one post by post_id. For enumeration or keyword search use listSingleImagePosts (with property=post_title property_operator=LIKE for keyword-in-body).

Required: post_id.

See also: listSingleImagePosts (enumerate many; supports keyword filter via property + property_operator=LIKE).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 lean-shaped record when found. Empty or HTTP 404 when not found.

Get post field definitions - Returns custom fields for a specific post type form.

Use when: discovering the per-post-type custom fields before building a create/update payload. Pass form_name of the target post type (e.g. blog_article_fields, events_fields, etc.).

Required: form_name.

Returns: a BARE ARRAY of field-definition objects (NOT wrapped in {status, message}). Each entry has key, label, required, type, and optionally choices (for dropdown/radio), default, helpText.

Silent-fallback warning: if form_name does NOT match a real post-type form, BD returns HTTP 200 with a generic SUPER-UNION field list (containing every possible post field including post_location, lat, lon, post_live_date, post_video, post_job, internals like post_type/logged_user/form_security_token) - and post_category.choices will be ABSENT. Always verify form_name exists first via listPostTypes (look for the matching row's form_name column). If your response has post_category WITHOUT a choices array, you hit the fallback.

Discovering post_category dropdown values: post_category is a per-post-type dropdown whose options come from the post type's feature_categories CSV (admin-managed). Read post_category.choices[].key for the exact values to send. BD does NOT trim whitespace when splitting the CSV - options after the first may have a leading space (e.g. " Category 2"). Pass VERBATIM.

Create a post - Create a new post record. Writes live data.

Use when: creating a blog article, event, job listing, coupon, or any other single-image post type. Look up data_id + data_type via listPostTypes first - the post type's data_type field determines which create endpoint is correct. If data_type=4 on the post type, use createMultiImagePost instead. For posts with scraped external image URLs, include auto_image_import=1 to fetch and store them locally.

Required: user_id, data_id, data_type.

Pre-check before create: BD does NOT enforce uniqueness on post_title, and BD auto-generates filename (the URL slug) from the title - so a duplicate title produces a URL collision (two posts fighting for the same public URL, unpredictable which one resolves). Do a server-side filter-find: listSingleImagePosts property=post_title property_value=<proposed> property_operator==. Zero rows = title free; >=1 row = taken. If post_title contains commas/colons/special chars (the = operator trips the CSV validator on those), switch to property_operator=like property_value=<distinctive-prefix>% using a 3-4-word prefix unique to this event. Do NOT paginate unfiltered lists - sites in the wild have thousands of posts; filtered lookup is one tiny response. If taken: reuse via updateSingleImagePost, OR ask the user, OR pick an alternate post_title and re-check. Never silently create a duplicate.

Parameter interactions:

• user_id - owner; must be an existing member (discover via listUsers or searchUsers)

• data_id - post type category ID; get via listPostTypes

• data_type - data type classification; usually matches the post type's data type

• post_status: 0=Draft (not visible), 1=Published (public)

• Response includes both post_id and post_token - the token is used for sharable URLs

See also: updateSingleImagePost (modify existing).

Which endpoint to use - data_type family decides:

Every post type in data_categories has a data_type field that classifies its family. Call listPostTypes or getPostType to see the data_type of your target post type, then choose:

If you call the wrong create endpoint for a given post type, BD may accept the row but it won't render on the public site correctly.

For "make a blog post" intent: look up data_categories for data_name matching "blog" (commonly data_id=14 with data_type=20) -> createSingleImagePost with that data_id + data_type.

For "make a photo album" / "gallery" intent: look up the album post type (often data_id=10, data_type=4) -> createMultiImagePost with that data_id + data_type. Photos are added separately via createMultiImagePostPhoto using the returned group_id.

Picking post_category (and other per-type dropdowns): post_category values are configured PER POST TYPE by the site admin in the post type's feature_categories CSV. Before create, call getSingleImagePostFields(form_name=<post type's form_name>) and read post_category.choices[].key. Pass ONLY values from that list, VERBATIM - BD does not trim whitespace when splitting feature_categories, so options after the first may have a leading space (e.g. " Category 2"). If the user names a category that isn't in the list: ask whether to pick the closest existing option or have them add the new option in BD admin first - do NOT invent a new value. WARNING: if form_name does not match a real post type form, getSingleImagePostFields silently returns a generic SUPER-UNION field list (HTTP 200, no error) - verify form_name exists in listPostTypes first.

Update a post - Update an existing post record by ID. Fields omitted are untouched. Writes live data.

Use when: editing post content, switching from draft to published (post_status=0->1), updating post title/caption, or correcting post metadata. To move a post to a different post type (rare), pass data_id - but validate the new post type is still in the single-image family.

Required: post_id.

Enums: post_status: 0=Draft (saved but not publicly visible), 1=Published (publicly visible on the site).

post_title rename does NOT update post_filename (the URL slug). post_filename is writable — see Rule: URL slug rename for when to suggest a slug update + redirect. Report post_filename from getSingleImagePost when giving the user a URL.

See also: createSingleImagePost (add new), deleteSingleImagePost (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete a post - Permanently delete a post record by ID. Destructive - cannot be undone via API.

Use when: removing a post permanently. For "hide without deleting" use updateSingleImagePost with post_status=0 (Draft). Deleting also removes the post_token, breaking any external links to the share URL.

Required: post_id.

See also: updateSingleImagePost (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List album groups - Paginated enumeration of portfoliogroup records. Read-only.

Lean-by-default keep-list: rows return only the core identity + routing fields: group_id, group_name, group_filename, group_status, data_id, data_type, system_name, data_name, data_filename, user_id, revision_timestamp, plus total_clicks (only when > 0), total_photos, cover_photo_url, cover_thumbnail_url rollups. Same keep-list as listSingleImagePosts (single-image fields like post_start_date simply won't appear on multi-image rows). Restore via flags: include_content=1 (full group_desc HTML), include_author_full=1 (full user nested — default omits author detail; call getUser(user_id) otherwise), include_clicks=1 (click array), include_photos=1 (full users_portfolio photo array shaped to PHOTO_LEAN_ALWAYS_KEEP), include_extras=1 (everything else: lat, lon, country_sn, state_sn, post_date, post_live_date, post_updated, post_token, etc.).

Use when: enumerating photo-album / gallery-style posts (Photo Album, Classified, Property, Product - any post type with data_type=4). For single-image post types use listSingleImagePosts.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getMultiImagePost (single record by ID). For keyword-in-body matching, use this tool with property=group_name property_operator=LIKE (or group_desc).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is lean-shaped per the keep-list above.

Get a single album group - Fetch a single portfoliogroup record. Read-only.

Lean-by-default keep-list: same shape as listMultiImagePosts — core identity + routing fields plus total_clicks (only when > 0), total_photos, cover_photo_url, cover_thumbnail_url. Restore via flags: include_content=1 (full group_desc HTML), include_author_full=1 (full user nested — default omits author detail; call getUser(user_id) otherwise), include_clicks=1, include_photos=1 (full users_portfolio photo array), include_extras=1 (everything else — geo, post dates, timestamps, tokens, etc.).

Use when: fetching one multi-image post by group_id. Photos in this post are loaded separately via listMultiImagePostPhotos with group_id filter.

Required: group_id.

See also: listMultiImagePosts (enumerate many; supports keyword filter via property + property_operator=LIKE).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 lean-shaped record when found. Empty or HTTP 404 when not found.

Get album group field definitions - Fetch field definitions for a multi-image post type form. Read-only.

Use when: discovering per-post-type custom fields for multi-image posts - same pattern as getSingleImagePostFields but for the users_portfolio_groups resource.

Required: form_name.

Returns: a BARE ARRAY of field-definition objects (NOT wrapped in {status, message}). Each entry has key, label, required, type, and optionally choices, default, helpText. Multi-image post fields seen: user_id, group_status, group_name, group_desc, post_image (CSV of image URLs), auto_image_import, post_tags, auto_geocode. Categorization for multi-image posts is exposed under an internal widget-controller field name, not a clean post_category - not straightforward to write via API.

Silent-fallback warning: if form_name does NOT match a real post-type form, BD may return a generic field list without error. Verify form_name exists in listPostTypes before trusting the response.

Create an album group - Create a new portfoliogroup record. Writes live data.

Use when: creating a photo album, gallery, product listing with multiple photos, or any post type with data_type=4. Confirm the target post type's data_type via listPostTypes first - data_type=4 belongs here; 9/20 belongs in createSingleImagePost. For external image URLs, always use the bulk post_image CSV + auto_image_import=1 here - this is the only path that imports externals into site storage. createMultiImagePostPhoto does NOT import and is only suitable for already-hosted-on-site URLs.

Required: user_id, data_id, data_type.

Pre-check before create: BD does NOT enforce uniqueness on group_name, and the public URL slug is derived from it — duplicate names produce a URL collision (unpredictable which resolves). Do a server-side filter-find: listMultiImagePosts property=group_name property_value=<proposed> property_operator==. Zero rows = name free; >=1 = taken. If taken: reuse via updateMultiImagePost, ask the user, or pick an alternate. Never silently create a duplicate.

Parameter interactions:

• data_id + data_type - specify the post type this album belongs to (from listPostTypes; data_type must be 4)

• group_status: 0=Hidden, 1=Published

• post_image - comma-separated image URLs imported as child photos at create time

• auto_image_import=1 - fetches the post_image URLs into site storage (required for external sources to survive)

Post-create verification (critical): HTTP 200 does NOT mean every photo imported. After create, call listMultiImagePostPhotos property=group_id&property_value=<new_group_id>&property_operator==; row count must equal CSV count and every row needs non-empty file + image_imported=2 (success; 0 = silent-failure row). Fix failed row: deleteMultiImagePostPhoto, then updateMultiImagePost group_id=<same>&post_image=<replacement>&auto_image_import=1 (appends). Do NOT delete and recreate the album.

See also: updateMultiImagePost (modify existing), createMultiImagePostPhoto (already-hosted URLs only).

Returns: { status: "success", message: {...createdRecord} } - includes the server-assigned group_id.

Which endpoint to use - data_type family decides:

Every post type in data_categories has a data_type field that classifies its family. Call listPostTypes or getPostType to see the data_type of your target post type, then choose:

If you call the wrong create endpoint for a given post type, BD may accept the row but it won't render on the public site correctly.

Category for multi-image posts: multi-image posts do NOT expose post_category like single-image posts do. Album-level categorization is configured differently in BD admin and is not cleanly writable via the create payload. If categorization is needed, add it via a follow-up updateMultiImagePost or BD admin.

Update an album group - Update an existing portfoliogroup record by ID. Fields omitted are untouched. Writes live data.

Use when: editing metadata (title, description, group_status) OR appending photos via post_image CSV + auto_image_import=1 (APPENDS, does not replace). Existing photos are edited via updateMultiImagePostPhoto (title/order only).

Required: group_id.

Enums: group_status: 0=Draft, 1=Published.

Verify appended photos via listMultiImagePostPhotos, NOT via getMultiImagePost.post_image. The parent's post_image field is a transient write-through, not a mirror of child rows — it does NOT reflect appended photos. Child rows land in users_portfolio. Silent-failure possible (empty file, image_imported=0) — check each child row.

group_name rename does NOT update group_filename (the URL slug). group_filename is writable — see Rule: URL slug rename for when to suggest a slug update + redirect. Report group_filename from getMultiImagePost when giving the user a URL.

See also: createMultiImagePost, deleteMultiImagePost, deleteMultiImagePostPhoto.

Returns: { status: "success", message: {...updatedRecord} } - photo rows land asynchronously.

Delete an album group - Permanently delete a portfoliogroup record by ID. Destructive - cannot be undone via API.

Use when: removing the entire album. Recommended sequence: delete child photos first via deleteMultiImagePostPhoto (enumerate via listMultiImagePostPhotos property=group_id&property_value=<id>&property_operator==), THEN delete the group. BD does not cascade — skipping this leaves orphan users_portfolio rows.

Required: group_id.

See also: updateMultiImagePost (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List album photos - Paginated enumeration of portfoliophoto records. Read-only.

Lean-by-default keep-list: rows return photo_id, user_id, group_id, file, original_image_url, title, order, status, image_imported, revision_timestamp. Marketplace fields (price, manufacturer, availability, product_category, product_type, condition, inv_id, link, additional_fields) restore via include_marketplace=1.

Use when: fetching all photos within a multi-image post - always pass group_id to filter. For a single photo by ID use getMultiImagePostPhoto. For image-dedup: property=original_image_url property_operator=in property_value=<URL1,URL2,URL3> returns matched rows with original_image_url in the lean response.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getMultiImagePostPhoto (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is lean-shaped per the keep-list above.

Get a single album photo - Fetch a single portfoliophoto record. Read-only.

Lean-by-default keep-list: same shape as listMultiImagePostPhotos — photo_id, user_id, group_id, file, original_image_url, title, order, status, image_imported, revision_timestamp. Marketplace fields restore via include_marketplace=1.

Use when: editing or removing one specific photo within an album. You need the photo_id (from listMultiImagePostPhotos).

Required: photo_id.

See also: listMultiImagePostPhotos (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Create an album photo - Create a new portfoliophoto record. Writes live data.

Use when: adding ONE image to an existing album where the image is already hosted on the BD site (or hotlinking is acceptable). The parent album must exist (call createMultiImagePost first to get group_id).

Does NOT import external URLs. This endpoint has no auto_image_import field — the URL is recorded as-is. The parent album's auto_image_import=1 applies only to photos passed via the parent's bulk post_image CSV at create time; it does NOT cascade to subsequent createMultiImagePostPhoto calls. For external URLs that must survive source outages (e.g. Pexels, stock sites), do NOT use this endpoint — create a NEW album via createMultiImagePost with a bulk CSV post_image + auto_image_import=1, and delete the old album.

Required: user_id, group_id.

Parameter interactions:

• group_id - parent album group (from createMultiImagePost or listMultiImagePosts)

• original_image_url - full URL of the image; must already be publicly accessible; stored verbatim (no fetch)

See also: createMultiImagePost (the correct path for external URLs), updateMultiImagePostPhoto (modify title/order only — cannot re-import).

Update an album photo - Update an existing portfoliophoto record by ID. Fields omitted are untouched. Writes live data.

Use when: reordering photos within an album (order field) or renaming (title).

Required: photo_id.

Cannot re-import a failed image. Only writes title and order. To fix an image_imported=0 row: deleteMultiImagePostPhoto, then updateMultiImagePost group_id=<same>&post_image=<new_url>&auto_image_import=1 (appends).

See also: createMultiImagePostPhoto (add new), deleteMultiImagePostPhoto (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete an album photo - Permanently delete a portfoliophoto record by ID. Destructive - cannot be undone via API.

Use when: permanently removing one photo from an album. For "hide" use updateMultiImagePostPhoto with status=0.

Required: photo_id.

See also: updateMultiImagePostPhoto (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List post types - Paginated enumeration of posttype records. Read-only.

Lean-by-default keep-list: rows return only the core identity + routing fields: data_id, data_type, system_name, data_name, data_filename, form_name, feature_categories, type_of_feature, is_event_feature, is_digital_product, revision_timestamp. Everything else stripped — restore via flags:

type_of_feature enum: 1 = events, 2 = real-estate properties, 0 = digital products, null = all other post types. Filter non-event/property/digital-product types by system_name / form_name / data_name — NOT by type_of_feature.

• include_code=1 - return the 8 PHP/HTML code-template fields (search_results_div, search_results_layout, profile_results_layout, profile_header, profile_footer, category_header, category_footer, comments_code). Use this when editing post-type templates.

• include_post_comment_settings=1 - return the post_comment_settings JSON-string field.

• include_review_notifications=1 - return the 5 review-notification email template fields.

• include_extras=1 - return everything else (h1, h2, icon, category_tab, profile_tab, per_page, profile_per_page, sidebar configs, always_on, distance_search, display_order, caption_length, data_active, and all per-page/per-tab display toggles).

Use when: discovering which post types exist on this site AND their data_type families. The data_type value on each row tells you whether a post type belongs to createSingleImagePost (9/20) or createMultiImagePost (4). Use this BEFORE calling either create endpoint to pick the correct tool.

Reserved data_types — default-excluded. 10 (Member Listings — use listUsers / searchUsers; opt-in rows omit data_filename — members live at /<user.filename>, member directory landing is /search_results, never /listing/<id>), 13 (Member Ratings), 21 (Member Categories — use listTopCategories / listSubCategories). To include reserved records, opt in via the property / property_value filter: property=data_type, property_value=10, property_operator== for a single value; property=data_type, property_value=10,4,9, property_operator=in for a comma-list mix of reserved and standard.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getPostType (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is lean-shaped per the keep-list above.

Get a single post type - Fetch a single posttype record. Read-only.

Lean-by-default keep-list: same shape as listPostTypes — returns only the core identity + routing fields: data_id, data_type, system_name, data_name, data_filename, form_name, feature_categories, type_of_feature, is_event_feature, is_digital_product, revision_timestamp. Restore via flags: include_code=1 (the 8 PHP/HTML code-template fields — required when you intend to edit them via updatePostType), include_post_comment_settings=1 (the post_comment_settings JSON), include_review_notifications=1 (the 5 review-notification email fields), include_extras=1 (everything else: h1, h2, icon, category_tab, profile_tab, per_page, profile_per_page, sidebar configs, always_on, distance_search, display_order, caption_length, data_active, and all per-page/per-tab display toggles).

Use when: checking the configuration of one post type (which data_type family, whether active, custom field config, current search-results / profile-page template code). Commonly followed by getPostTypeCustomFields to enumerate per-type fields. Also the canonical read before any updatePostType code-field edit — apply Rule: Post-type code fields.

Required: data_id.

Code-field master-fallback: the up to eight HTML/PHP code fields on every post type record (category_header, search_results_div, category_footer, profile_header, profile_results_layout, profile_footer, search_results_layout, comments_code) begin life backed by the BD-core master template and only persist locally in the site DB when an admin (or API call) saves them. This endpoint returns the MASTER value for any code field that has no local override (when include_code=1) - so the agent always sees the real rendered code, not an empty string. This matters because any edit to one of the grouped code fields (search-results group = header+loop+footer, profile group = header+body+footer) MUST include all fields in that group on the write (see Rule: Post-type code fields). Always pass include_code=1 and read current values here BEFORE calling updatePostType for code-field edits.

Reserved data_types — not reachable here. If the resolved record's data_type is 10 (Member Listings), 13 (Member Ratings), or 21 (Member Categories), this endpoint returns message: [] (empty). To access these records, use listPostTypes property=data_type property_value=<value> (e.g. property_value=10) which returns the same data. Member Listings rows omit data_filename — members live at /<user.filename>, member directory landing is /search_results, never /listing/<id>.

See also: listPostTypes (enumerate many; reserved data_types default-excluded, opt-in via property=data_type, property_value=<value>), updatePostType (write; applies Rule: Post-type code fields and Rule: Member Listings post type), getPostTypeCustomFields (per-type custom field enum).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 lean-shaped record when found. Empty or HTTP 404 when not found.

Get custom fields for a post type - Fetch a single posttypecustomfields record. Read-only.

Use when: building a create/update payload for a post type that has custom fields (most do). Returns the exact per-type schema to send.

Required: exactly one of data_id (numeric post-type ID) OR system_name (string, e.g. website_blog_article). When system_name is given the wrapper resolves it to data_id via listPostTypes before calling BD.

Parameter interactions:

• data_id - the post type to introspect; get via listPostTypes

• system_name - friendlier alternative; the wrapper does the lookup

• Returns custom field definitions specific to this post type - use to build create/update payloads for matching posts

Discovering enumerated field values (e.g. post_category): per-post-type dropdowns like post_category are configured by the site admin and live in this schema. There is NO createPostCategory API tool - if the user needs a new dropdown option, that is admin-side work. Call this before a create/update to see the exact allowed values for select/radio/checkbox fields, and pass only those values verbatim.

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Update a post type - Update a post type. PATCH semantics (except per Rule: Post-type code fields). Writes live data.

Cache refresh is automatic. Response includes auto_cache_refreshed: true after successful writes; no manual refreshSiteCache call needed. If auto_cache_refreshed: false, check auto_cache_refresh_error and retry refreshSiteCache once.

Required: data_id.

Picking the right post type — disambiguation. Apply Rule: Resource disambiguation before editing. "Edit my classifieds page" is layer-ambiguous (a WebPage vs. the post type's code group vs. Member Listings UI vs. a category landing) — confirm WHICH layer even when only one record string-matches. Resolve to data_id via listPostTypes first; never proceed on semantic similarity alone.

Use when: toggling a post type active/inactive, renaming, changing per-page display counts, editing search-results UI or profile-page code. For Member Listings specifically: tuning keyword-search, pagination, sidebar, sort order. Custom field DEFINITIONS live in BD admin UI, not API.

Universal structural safety - NEVER mutate these fields on ANY post type: data_type, system_name, data_name, data_active, data_filename, form_name, software_version, display_order. BD system-seeds them; changes break rendering site-wide.

MEMBER LISTINGS SPECIAL CASE (data_type=10). Every BD site has exactly one post type with data_type=10 (system_name=member_listings) - it controls the Member Search Results page UI/UX. No profile/detail page of its own - members render via the normal profile system. data_id varies per site; discover via listPostTypes property=data_type property_value=10 property_operator==. Cache the data_id for the session - it never changes.

Member Listings cheat-sheet (12 commonly-edited UI/UX settings + 3 search-code fields - NOT a limit, any real column is writable per schema-is-documentation): h1, h2, per_page, keyword_search_filter, enableLazyLoad, category_order_by, category_ignore_search_priority, post_type_cache_system, category_sidebar, sidebar_search_module, sidebar_position_mobile, enable_search_results_map, category_header, search_results_div, category_footer.

Member Listings guardrails (apply ONLY to data_type=10):

• profile_header / profile_results_layout / profile_footer / search_results_layout have NO effect on Member Listings - skip them.

• data_active must stay 1; no legitimate reason to disable via API.

• On other post types (blog, event, coupon, property, product), these ARE legitimate rendering fields - write freely.

CODE FIELDS - master-fallback on GET + all-or-nothing save per group. Up to 8 code-template fields begin life backed by BD's MASTER post-type template; they only persist locally when saved. GET returns master value for un-customized fields (agent sees real rendered code, not empty string). Writing ANY field in a group requires sending ALL fields in that group (unchanged fields copied verbatim from prior GET); omitting group-mates causes them to drift back to master on next render.

Groups:

1. Search-results (every post type INCLUDING Member Listings): category_header + search_results_div + category_footer. Send all 3.

2. Profile/detail (post types WITH detail pages - NOT Member Listings): profile_header + profile_results_layout + profile_footer. Send all 3. DO NOT send on Member Listings.

3. Standalone (post types WITH detail pages - NOT Member Listings): search_results_layout (single.php analogue - misleading name) and comments_code (auxiliary footer, embeds/schema/pixels). Both save independently, no group rule. Master-fallback applies. DO NOT send on Member Listings.

Code-edit workflow:

1. getPostType(data_id) - returns current values with master fallback.

2. Identify target group.

3. Build payload: changed field(s) + other group-mates copied verbatim from GET.

4. updatePostType with data_id + full group. (Cache flush is automatic post-write.)

Code-field trust level: all 8 code fields are widget-equivalent - accept arbitrary HTML/CSS/JS/iframes/PHP (BD evaluates PHP server-side at render). XSS/SQLi sanitization rules do NOT apply - anyone editing post-type code already has full site code control. Supports PHP variables (<?php echo $user_data['full_name']; ?>) and BD text-label tokens (%%%text_label%%%).

Member Listings code edits affect every member-search page on the site - confirm intent with user before editing Member Listings code fields.

See also: getPostType, listPostTypes (filter by data_type), deletePostType (NOT for Member Listings - system-required).

Returns: { status: "success", message: {...updatedRecord}, auto_cache_refreshed: true|false, auto_cache_refresh_error?: "..." }.

Delete a post type - Permanently delete a posttype record by ID. Destructive - cannot be undone via API.

Use when: removing a post type entirely. Existing posts of this type become orphaned - consider migrating them to another type first via a bulk updateSingleImagePost/updateMultiImagePost.

Required: data_id.

See also: updatePostType (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List unsubscribe records - Paginated enumeration of unsubscribe records. Read-only.

Use when: auditing the email unsubscribe list - useful for compliance (GDPR, CAN-SPAM) or before launching a new email campaign.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getUnsubscribe (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the full resource object.

Get a single unsubscribe record - Fetch a single unsubscribe record. Read-only.

Use when: checking one unsubscribe record by ID.

Required: id.

See also: listUnsubscribes (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Add email to unsubscribe list - Create a new unsubscribe record. Writes live data.

Use when: programmatically opting a member out of emails (e.g., from an external unsubscribe form or CRM sync). BD adds entries itself when members click email unsubscribe links.

Required: email.

Enums: definitive: 0, 1.

See also: updateUnsubscribe (modify existing).

email is the only meaningful input. Pass the email address to opt out. BD adds unsubscribe records to its global unsubscribe list - this applies across all email campaigns for the site. There is no "unsubscribe from some lists but not others" granularity via this endpoint; it's all-or-nothing.

Update an unsubscribe record - Update an existing unsubscribe record by ID. Fields omitted are untouched. Writes live data.

Use when: editing an unsubscribe record. Rare.

Required: id.

Enums: definitive: 0, 1.

See also: createUnsubscribe (add new), deleteUnsubscribe (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Remove email from unsubscribe list - Permanently delete a unsubscribe record by ID. Destructive - cannot be undone via API.

Use when: re-subscribing a member (remove their unsubscribe entry). Confirm the member's consent first - don't use to silently re-enable emails.

Required: id.

See also: updateUnsubscribe (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List widgets - Paginated enumeration of widget records. Read-only.

Use when: discovering the reusable HTML/CSS/JS components available for embedding in pages (via [widget=Name] shortcode) or email templates. For fetching one specific widget by ID use getWidget.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability. Useful filter: widget_viewport=front to list only public-facing widgets.

See also: getWidget (single by ID), createWidget (add new), updateWidget (modify).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record carries the full widget object (fields enumerated in the table that follows).

Widget object fields (from BD support article 12000108056):

Get a single widget - Fetch a single widget record by widget_id. Returns the raw HTML/CSS/JS source. Read-only.

Use when: you have a widget_id (from listWidgets or admin) and want the widget's SOURCE code to edit or audit. To preview the rendered widget on the front-end, embed it on a page via [widget=Name] shortcode and view the page.

Required: widget_id (path parameter).

See also: listWidgets (enumerate), updateWidget (modify).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record with all widget fields (widget_data = HTML, widget_style = CSS, widget_javascript = JS, plus metadata).

For the full field list, see listWidgets.

Create a widget - Create a new widget (reusable HTML/CSS/JS component). Writes live data.

Cache refresh is automatic. Response includes auto_cache_refreshed: true after successful writes; no manual refreshSiteCache call needed. If auto_cache_refreshed: false, check auto_cache_refresh_error and retry refreshSiteCache once.

Use when: programmatically adding a new reusable block to embed via [widget=Name] shortcode on pages or email templates. Rare in practice - widgets are usually created via BD admin UI where the editor supports live preview. API creation is useful for bulk imports, cross-site migrations, or scripted widget generation.

Required: widget_name (should be unique per site).

widget_name format: alphanumeric + spaces + hyphens + plus + underscores only ([A-Za-z0-9 -+_]+). Special chars (slashes, dots, ampersands, quotes, brackets, etc.) break [widget=Name] shortcode resolution and are runtime-rejected by the wrapper. Examples: Mortgage Calculator, Service-Card, Email_Validator_v2, C++ Course.

Pre-check before create: BD does NOT enforce uniqueness on widget_name. Duplicates break [widget=Name] shortcode resolution - which widget renders at the shortcode is undefined. Do a server-side filter-find: listWidgets property=widget_name property_value=<proposed> property_operator==. Zero rows = name free; >=1 row = taken. Do NOT paginate unfiltered lists looking for the name - on sites with hundreds of custom widgets that burns rate limit for nothing.

On collision (auto-suffix flow): if the proposed name is taken, append -v2 and re-check. Still taken? Try -v3, -v4, ... up through -v10. First free suffix wins. Only if all 10 are taken, ask the user for a different base name. Never silently create a duplicate.

Route by type BEFORE writing values: decide what each piece of code is, then put it in the matching field — HTML → widget_data, CSS → widget_style, JS → widget_javascript. A self-contained block with all three concatenated into widget_data will save successfully but silently break: widget_data strips backslashes on render, mangling regex literals (\d, \s), string escapes (\n, \t), and unicode escapes (\u0022). The other two fields do not strip backslashes. Split by type from the start.

Common fields on create:

• widget_data - the HTML content

• widget_style - CSS (scoped to the widget via widget_class or div_id)

• widget_javascript - JS (runs when widget is rendered on a page)

• widget_viewport - front (public), admin (admin panel only), or both

• bootstrap_enabled=1 - ensures Bootstrap framework loaded when this widget is rendered

• widget_html_element - wrapper element (default div)

See also: updateWidget (modify existing), listWidgets (check if name is taken first), getWidget (verify storage after create).

Writes live data: the widget is available immediately but does nothing until referenced by a [widget=Name] shortcode on a page or email template.

Returns: { status: "success", message: {...createdRecord}, auto_cache_refreshed: true|false, auto_cache_refresh_error?: "..." } including the new widget_id.

Post-create verification (recommended, especially when uncertain about routing): call getWidget once to confirm widget_data contains only HTML, widget_style contains your CSS, and widget_javascript contains your JS wrapped in <script>...</script>. If anything landed in the wrong field, call updateWidget to relocate before the user tests the widget. Proactive relocation here is correct and does NOT violate the "don't relocate without user-reported breakage" rule on updateWidget — that rule applies to subsequent edits, not to self-correcting your own just-created record.

For the full field list, see listWidgets.

Update a widget - Update an existing widget by widget_id. Fields omitted are untouched. Writes live data.

Cache refresh is automatic. Response includes auto_cache_refreshed: true after successful writes; no manual refreshSiteCache call needed. If auto_cache_refreshed: false, check auto_cache_refresh_error and retry refreshSiteCache once.

Use when: editing widget HTML (widget_data), CSS (widget_style), JS (widget_javascript), or metadata. Any page or email referencing this widget via [widget=Name] shortcode will render the updated content on next view.

Required: widget_id.

Common edits:

• Content: widget_data, widget_style, widget_javascript

• Visibility: widget_viewport (front/admin/both)

• Framework: bootstrap_enabled, mobile_enabled, ssl_enabled

Renaming via widget_name: DO NOT pass widget_name unless the user explicitly asks to rename the widget. Renaming a widget breaks every [widget=Name] shortcode reference to its old name on every page/email — silently. If the user does ask: same format rules as create ([A-Za-z0-9 -+_]+, runtime-rejected on bad chars); on collision follow the auto-suffix flow (-v2, -v3, ... up to -v10).

See also: createWidget (add new), deleteWidget (remove).

Writes live data: edits go live immediately for new page loads.

Returns: { status: "success", message: {...updatedRecord}, auto_cache_refreshed: true|false, auto_cache_refresh_error?: "..." }.

For the full field list, see listWidgets.

Delete a widget - Permanently delete a widget by widget_id. Destructive - cannot be undone via API.

Use when: removing an unused widget. For "disable without deleting" use updateWidget with widget_viewport=admin (hides from public pages) - preserves the source for later use.

Destructive caveat: any page or email using [widget=Name] shortcode referencing the deleted widget will render as empty or broken at that spot. Audit with listWidgets + check page content for shortcodes referencing this widget's widget_name or short_code before deleting.

Required: widget_id.

See also: updateWidget with widget_viewport=admin (reversible hide).

Returns: { status: "success", message: "data_widgets record was deleted" }.

Render a widget to HTML - Diagnostic tool only. Returns BD's rendered HTML output for a widget — useful for confirming render-pipeline symptoms during troubleshoot (backslash strip on widget_data, <style> auto-wrap on widget_style, <script> wrapper presence on widget_javascript). Production widget rendering on a customer's site is always via [widget=Name] shortcode in page or email content — never call this tool to deliver widget HTML to end users.

Use when: the user reports a widget is broken and you need to see what BD's render pipeline actually emits. See Rule: Widget code fields scenario 3 (TROUBLESHOOT).

Required: either widget_id OR widget_name.

Returns (distinct from standard envelope): { status, message, name, output }. The output field contains rendered widget_data HTML with template tokens expanded, plus BD's auto-wrapped <style type='text/css'>-block from widget_style, plus the verbatim widget_javascript content. CSS and JS are NOT in output if their fields are empty.

See also: getWidget (raw source for inspecting field placement), updateWidget (apply fixes after diagnosis).

List email templates - Paginated enumeration of emailtemplate records. Read-only.

Use when: enumerating the site's transactional/marketing email templates before editing. Common audit: before bulk updating "from" addresses or footers.

Lean-by-default: email_body (the HTML body, the heaviest field per row) is stripped. All identity/metadata fields (email_id, email_name, email_subject, email_type, category_id, notemplate, etc.) are always kept. Set include_body=1 to restore.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getEmailTemplate (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the full resource object minus email_body unless include_body=1.

Get a single email template - Fetch a single emailtemplate record. Read-only.

Use when: fetching one template's HTML body and subject for edit.

Required: email_id.

Lean-by-default: email_body is stripped. Set include_body=1 to restore it (always do this when you need to edit the HTML).

See also: listEmailTemplates (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Record omits email_body unless include_body=1. Empty or HTTP 404 when not found.

Create an email template - Create a new emailtemplate record. Writes live data.

Use when: adding a new transactional/marketing template. Rare - most BD email templates are built into the admin UI.

Required: email_name.

Pre-check before create: BD does NOT enforce uniqueness on email_name. Duplicates cause the wrong template to fire on transactional triggers. Do a server-side filter-find: listEmailTemplates property=email_name property_value=<proposed> property_operator==. Zero rows = name free; >=1 row = taken. Do NOT paginate unfiltered lists looking for the name - on sites with many templates that burns rate limit for nothing. If taken: reuse via updateEmailTemplate, OR ask the user, OR pick an alternate email_name and re-check. Never silently create a duplicate.

Enums: signature: 0/1; notemplate: default 2 (template + logo center); other values 0 (logo left), 3 (logo right), 4 (template, no logo), 1 (plaintext-only, no wrapper); category_id: default 0 (My Saved Templates) — 1/3/4/15/16 are system-populated, do NOT create under them; unsubscribe_link: 0/1.

Parameter interactions:

• email_subject and email_body can use template tokens (e.g. %%%website_name%%%, recipient field tokens)

• email_body supports HTML

See also: updateEmailTemplate (modify existing).

On create: email_name is the only required field. Subject and body are optional at create time - you can create a template stub and fill in email_subject / email_body via updateEmailTemplate later. This lets you programmatically scaffold templates before customizing them via the admin UI.

Update an email template - Update an existing emailtemplate record by ID. Fields omitted are untouched. Writes live data.

Use when: editing any field on an existing template — subject, body, wrapper mode (notemplate), category, signature, triggers, etc. Mirrors createEmailTemplate field-for-field; only email_id is required.

Required: email_id.

Enums (same as createEmailTemplate): signature: 0/1; notemplate: 0 (logo left), 2 (logo center), 3 (logo right), 4 (template, no logo), 1 (plaintext-only, no wrapper); category_id: 0/1/3/4/15/16 (unrestricted on update); unsubscribe_link: 0/1.

See also: createEmailTemplate (add new), deleteEmailTemplate (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } — the full updated record after changes applied.

Delete an email template - Permanently delete a emailtemplate record by ID. Destructive - cannot be undone via API.

Use when: removing a deprecated template. BD may fall back to defaults if a required system template is deleted - confirm before purging.

Required: email_id.

See also: updateEmailTemplate (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List forms - Paginated enumeration of form records. Read-only.

Use when: enumerating the site's forms (signup, contact, quote request, custom forms). Child fields are fetched separately via listFormFields.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getForm (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the full resource object.

Get a single form - Fetch a single form record. Read-only.

Use when: fetching one form's metadata.

Required: form_id.

See also: listForms (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Create a form - Create a new form record. Writes live data. Add fields afterward via createFormField.

Required: form_name, form_title, form_action, form_layout, form_table, form_url, form_class, table_index, form_action_div, form_email_on, form_success_message.

Class selection — see Rule: Forms § Form classes before picking form_table. Follow § Form-level recipe for the canonical creation recipe.

Mandatory form_name pre-check per Rule: Pre-check natural keys — BD does NOT enforce uniqueness; duplicate form_name produces ambiguous [form=…] shortcode resolution.

Wrapper-enforced refusal: form_action_type=redirect AND empty form_target → call refused (see Rule: Forms § Wrapper-enforced invariants).

See also: updateForm, createFormField, listFormFields.

Returns: { status: "success", message: {...createdRecord} }.

Update a form - Update an existing form record by ID. Fields omitted are untouched. Writes live data.

Required: form_id.

Cross-refs same as createForm — see Rule: Forms § Form-level recipe / § Lead-match / § Member-dashboard. Before flipping form_action_type to a public-facing value, run listFormFields to confirm the tail pattern exists.

Wrapper-enforced refusal: form_action_type=redirect AND empty form_target → call refused.

See also: createForm, deleteForm, listFormFields / createFormField.

Returns: { status: "success", message: {...updatedRecord} }.

Delete a form - Permanently delete a form record by ID. Destructive - cannot be undone via API.

Use when: removing a form - child fields orphan.

Required: form_id.

See also: updateForm (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List form fields - Paginated enumeration of formfield records. Read-only.

Use when: listing fields on a form. Filter by form_name (text slug — form_fields joins to forms by form_name, not form_id).

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getFormField (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is the full resource object.

Get a single form field - Fetch a single formfield record. Read-only.

Use when: one field by ID.

Required: field_id.

See also: listFormFields (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 record when found. Empty or HTTP 404 when not found.

Create a form field - Create a new formfield record. Writes live data.

Required: form_name, field_name, field_text, field_type, field_order.

Canonical field_name for form_table=website_contacts: yourname / inquiry_email / phone / comments (NOT name / email / message — those persist but don't surface in the admin inbox columns). Anything else = custom field_name. Full table at Rule: Forms § Form classes.

See Rule: Forms § Field anatomy for field shape, view-flag defaults, validators, and the canonical json_meta skeleton. § Form-level recipe covers the tail pattern. § Lead-match / § Member-dashboard cover special-case forms.

Wrapper-enforced refusals: (1) field_required=1 with field_type ∈ {HoneyPot, HTML, Tip, Button} — Hidden is allowed. (2) field_type not in the canonical enum (strict case match; textarea is the lone lowercase value). (3) field_type=Hidden with empty field_name or empty field_text. (4) Non-binary value on any of field_required / field_input_view / field_display_view / field_email_view / field_search_view / field_grid_view / field_input_view_admin_only (empty / omitted accepted — BD applies per-field defaults).

Agent pre-checks (NOT wrapper-enforced): field_name uniqueness within form, single submit element per form. See Rule: Forms § Wrapper-enforced invariants → Agent-side responsibilities.

See also: updateFormField, listFormFields.

Update a form field - Update an existing formfield record by ID. Fields omitted are untouched. Writes live data.

Required: field_id.

When renaming field_name on a form_table=website_contacts form, use canonical names (yourname / inquiry_email / phone / comments) — see createFormField and Rule: Forms § Form classes.

See Rule: Forms § Field anatomy for field shape, view-flag defaults, validators, and the canonical json_meta skeleton.

Wrapper-enforced refusals: (1) field_required=1 with field_type ∈ {HoneyPot, HTML, Tip, Button} — Hidden is allowed. (2) field_type not in the canonical enum (strict case match; textarea is the lone lowercase value). (3) field_type=Hidden with empty field_name or empty field_text. (4) Non-binary value on any of field_required / field_input_view / field_display_view / field_email_view / field_search_view / field_grid_view / field_input_view_admin_only (empty / omitted accepted — BD applies per-field defaults).

Agent pre-checks (NOT wrapper-enforced): field_name uniqueness within form, single submit element per form. See Rule: Forms § Wrapper-enforced invariants → Agent-side responsibilities.

See also: createFormField, deleteFormField, listFormFields.

Delete a form field - Permanently delete a formfield record by ID. Destructive - cannot be undone via API.

Use when: removing a field. Existing submission records may reference the old field name - data persists but becomes orphan metadata.

Required: field_id.

See also: updateFormField (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List membership plans - Paginated enumeration of membership-plan records. Read-only.

Use when: discovering subscription_id values to use when creating members. Essential prerequisite for createUser - every member needs a valid subscription_id.

Lean-by-default keep-list: rows return only the core 10 fields: subscription_id, subscription_name, subscription_type, profile_type, monthly_amount, yearly_amount, initial_amount, lead_price, searchable, data_settings. data_settings is the comma-separated list of post-type IDs this plan can publish — kept by default to support author-resolution flows (find plans whose members can publish a given post type). Everything else stripped — restore via flags:

• include_plan_config=1 - restores config bundle (active/searchable toggles, limits, forms, sidebars, email templates, upgrade chain, payment defaults, etc.).

• include_plan_display_flags=1 - restores show_* profile-visibility toggles.

• include_extras=1 - returns the full BD plan row, untouched (every column).

Pagination: cursor-based (limit, page). See Rule: Pagination.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators.

See also: getMembershipPlan (single by ID).

Returns: { status: "success", total, ..., message: [...records] }.

Get a single membership plan - Fetch a single membership-plan record. Read-only.

Use when: fetching one plan's config. Same lean-by-default as listMembershipPlans.

Required: subscription_id.

Lean-by-default keep-list: the 10 core fields — subscription_id, subscription_name, subscription_type, profile_type, monthly_amount, yearly_amount, initial_amount, lead_price, searchable, data_settings. Opt in to restore:

• include_plan_config=1 - config bundle (limits, sidebars, forms, email templates, upgrade chain, payment defaults).

• include_plan_display_flags=1 - show_* profile-visibility toggles.

• include_extras=1 - returns the full BD plan row, untouched.

EAV-routed fields not merged: custom_checkout_url (and any future EAV-routed plan fields) are stored in users_meta and NOT returned by this endpoint even with include_plan_config=1. Read via listUserMeta database=subscription_types database_id=<subscription_id> to fetch them.

See also: listMembershipPlans (enumerate).

Returns: { status: "success", message: [{...record}] }.

Create a membership plan - Create a new membershipplan record. Writes live data.

Use when: launching a new plan tier. Rare - usually configured in BD admin UI. Check profile_type carefully: paid, free, or claim - changing later affects billing and visibility.

Required: subscription_name, profile_type.

Pre-check before create: BD does NOT enforce uniqueness on subscription_name. Duplicate plan names confuse admins at signup-form configuration, billing reports, and member migration. Do a server-side filter-find: listMembershipPlans property=subscription_name property_value=<proposed> property_operator==. Zero rows = name free; >=1 row = taken. Do NOT paginate unfiltered lists - filtered lookup is one tiny response. If taken: reuse via updateMembershipPlan, OR ask the user, OR pick an alternate subscription_name and re-check. Never silently create a duplicate.

Enums: payment_default: yearly, monthly.

Parameter interactions:

• subscription_type - typically member for standard member plans

• profile_type: paid, free, or claim - controls how profile visibility and billing work

• monthly_amount / yearly_amount - price in the site's currency

• sub_active=1 makes the plan available for new signups; sub_active=0 grandfathers existing members only

• searchable=1 makes members on this plan findable in public search

See also: updateMembershipPlan (modify existing).

Update a membership plan - Update an existing membershipplan record by ID. Fields omitted are untouched. Writes live data.

Use when: adjusting pricing (monthly_amount/yearly_amount), toggling sub_active (new-signup availability), or changing feature flags like searchable, photo_limit. Changes apply to NEW signups; existing members on this plan keep their original terms unless manually migrated.

Required: subscription_id.

See also: createMembershipPlan (add new), deleteMembershipPlan (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete a membership plan - Permanently delete a membershipplan record by ID. Destructive - cannot be undone via API.

Use when: retiring a plan that has no members (or all its members have been migrated). Members with matching subscription_id become orphaned - migrate them first via updateUser.

Required: subscription_id.

See also: updateMembershipPlan (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List menus - Paginated enumeration of menu records. Read-only.

Lean-by-default keep-list: rows return only menu_id, menu_name, menu_title, revision_timestamp. Styling/target/rel/json_meta fields stripped — restore via include_extras=1 when editing menu appearance.

Use when: enumerating navigation menus on the site (main menu, footer menu, sidebar, etc.). For items within a menu use listMenuItems with menu_id filter.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getMenu (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is lean-shaped per the keep-list above.

Get a single menu - Fetch a single menu record. Read-only.

Lean-by-default keep-list: same shape as listMenus — returns only menu_id, menu_name, menu_title, revision_timestamp. Restore styling/target/rel/json_meta via include_extras=1.

Use when: fetching one menu's metadata. Child items are fetched separately.

Required: menu_id.

See also: listMenus (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 lean-shaped record when found. Empty or HTTP 404 when not found.

Create a menu - Create a new menu record. Writes live data.

Use when: adding a new navigation container. After creating the container, add entries via createMenuItem using the returned menu_id.

Required: menu_name, menu_title.

Pre-check before create: BD does NOT enforce uniqueness on menu_name. Duplicates cause the wrong menu to render wherever the menu is referenced. Do a server-side filter-find: listMenus property=menu_name property_value=<proposed> property_operator==. Zero rows = name free; >=1 row = taken. Do NOT paginate unfiltered lists - filtered lookup is one tiny response. If taken: reuse via updateMenu, OR ask the user, OR pick an alternate menu_name and re-check. Never silently create a duplicate.

Parameter interactions:

• menu_name (max 35 chars) - the internal identifier

• menu_title - the visible heading

• menu_active: 0=Inactive, 1=Active

See also: updateMenu (modify existing).

Update a menu - Update an existing menu record by ID. Fields omitted are untouched. Writes live data.

Use when: renaming a menu, toggling menu_active, or adjusting its CSS/HTML wrapper attributes.

Required: menu_id.

See also: createMenu (add new), deleteMenu (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete a menu - Permanently delete a menu record by ID. Destructive - cannot be undone via API.

Use when: removing a menu container. Child items (menu_items rows with matching menu_id) become orphaned - delete them first.

Required: menu_id.

See also: updateMenu (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List menu items - Paginated enumeration of menuitem records. Read-only.

Lean-by-default keep-list: rows return only menu_item_id, menu_name, menu_link, menu_order, menu_id, master_id. Styling/target/rel/json_meta, plus revision_timestamp / menu_title / menu_display / tablesExists (rarely actionable on read), are stripped — restore via include_extras=1.

Default empty-link filter: rows where menu_link is empty/null (infrastructure nodes — section headers, placeholders) are excluded by default. They can't be link targets. Opt in with include_empty_links=1 only when auditing the full menu structure.

Use when: enumerating items in a menu - always filter by menu_id. Use master_id filter for sub-menu items.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getMenuItem (single record by ID).

Returns: { status: "success", total, current_page, total_pages, next_page, prev_page, message: [...records] }. Each record is lean-shaped per the keep-list above. total reflects post-filter count when include_empty_links=0.

Get a single menu item - Fetch a single menuitem record. Read-only.

Lean-by-default keep-list: same shape as listMenuItems — returns only menu_item_id, menu_name, menu_link, menu_order, menu_id, master_id. Restore styling/target/rel/json_meta + the rarely-actionable revision_timestamp / menu_title / menu_display / tablesExists via include_extras=1.

Use when: editing one specific menu entry. Single-record fetch does NOT apply the empty-link filter — caller asked for this specific row by ID and gets it back.

Required: menu_item_id.

See also: listMenuItems (enumerate many).

Returns: { status: "success", message: [{...record}] } - the message array contains 1 lean-shaped record when found. Empty or HTTP 404 when not found.

Create a menu item - Create a new menuitem record. Writes live data.

Use when: adding a nav link to an existing menu. Parent menu_id must exist. For nested items pass master_id=<parent menu_item_id>; for top-level pass 0. menu_order determines display position (lower = earlier).

Required: menu_id, menu_name, menu_link, master_id, menu_order.

Enums: menu_active: 0=Inactive, 1=Active.

Parameter interactions:

• menu_id - parent menu container (from createMenu or listMenus)

• master_id - 0 for top-level items; for nested items, the ID of the parent menu item

• menu_order - display position within the parent menu (integer, lower = earlier)

• menu_target: _blank (new tab) or _self (same window)

See also: updateMenuItem (modify existing).

Update a menu item - Update an existing menuitem record by ID. Fields omitted are untouched. Writes live data.

Use when: renaming, re-linking (change menu_link), reordering (change menu_order), or hiding (change menu_active=0).

Required: menu_item_id.

See also: createMenuItem (add new), deleteMenuItem (remove permanently).

Returns: { status: "success", message: {...updatedRecord} } - the full updated record after changes applied.

Delete a menu item - Permanently delete a menuitem record by ID. Destructive - cannot be undone via API.

Use when: removing a single menu entry.

Required: menu_item_id.

See also: updateMenuItem (modify without removing).

Destructive: confirm intent with the user before bulk use. No soft-delete via API - records removed are not recoverable.

Returns: { status: "success", message: "record was deleted" }. No body beyond the confirmation string.

List services (sub-categories) - Paginated enumeration of SUB-level member categories (services). Read-only.

Lean by default: each row keeps service_id, profession_id (parent Top Category link), master_id (parent Sub Category for sub-sub), name, filename. Strips desc, keywords, image, icon, sort_order, lead_price, revision_timestamp. Pass include_category_schema=1 to restore all category metadata. Hierarchy is always visible so agents can traverse top -> sub -> sub-sub without opt-in.

Sub Categories are level 2 of the 3-tier member classification (e.g., "Sushi" under "Restaurants"). Each has a profession_id pointing at its parent Top Category. master_id points at a parent Sub Category for sub-sub-category nesting (master_id=0 = directly under a Top Category). Backed by BD's list_services table.

Use when: enumerating sub-categories (services) - always filter by profession_id to scope to one Top Category, otherwise you get all sub-cats across all tops (noisy). For sub-sub nesting, master_id filter narrows further.

Permission note - platform gap: this endpoint (/api/v2/list_services/*) is NOT in BD's public Swagger spec, so the admin's API key permissions UI does NOT auto-generate a toggle for it. The admin's "Services" toggle gates the Swagger-documented /api/v2/service/* endpoints (a DIFFERENT legacy table) - enabling that toggle does NOT grant access here. On 403: admin must manually INSERT a row into bd_api_key_permissions for endpoint_path='/api/v2/list_services/get' (and the singular /api/v2/list_services/get/{service_id} for getSubCategory). Do NOT substitute /api/v2/service/* - different table, inconsistent data.

Pagination: cursor-based (limit, page). See Rule: Pagination for full cursor/cap/stop semantics.

Filter/sort: property+property_value+property_operator, order_column+order_type. See Rule: Filter operators for the verified-working operator set, silent-drop detection, and derived-field unfilterability.

See also: getSubCategory (single by ID), listTopCategories (parents), createSubCategory (add new).

Returns: { status: "success", total, ..., message: [...records] }. Each record has service_id, name, desc, profession_id, master_id, filename, keywords, sort_order, lead_price, image.

How a member gets classified on their public profile:

• users_data.profession_id -> points at a single Top Category (the member's primary classification; shown in URL slug)

• users_data.services -> CSV of Sub Category IDs the member is tagged with (multiple allowed; simpler than the join table)

• rel_services rows (Member ↔ Sub Category links) -> used when you need per-link metadata like avg_price, specialty, num_completed. Optional; most sites use just the CSV field.

Sub-sub-categories: createSubCategory with master_id=<parent service_id> creates a Sub Category nested under another Sub Category (a "sub-sub"). master_id=0 (default) means the Sub Category sits directly under a Top Category (the profession_id).

There is NO createProfession or createService tool in this MCP — those are BD's internal table names. Use createTopCategory / createSubCategory instead (BD's table-name → tool-name mapping is documented in Rule: Table to endpoint).

Get a single service - Fetch a single SUB-level member category (service) by service_id. Read-only.

Lean by default: keeps service_id, profession_id, master_id, name, filename. Strips SEO metadata (desc, keywords, image, icon, sort_order, lead_price, revision_timestamp). Pass include_category_schema=1 to restore.

Use when: fetching one sub-category by service_id - usually after discovering it via listSubCategories.

Required: service_id (path).

See also: listSubCategories (enumerate; filter by profession_id for scope), getTopCategory (fetch parent Top by profession_id).

Returns: { status: "success", message: [{...record}] }.

How a member gets classified on their public profile:

• users_data.profession_id -> points at a single Top Category (the member's primary classification; shown in URL slug)

• users_data.services -> CSV of Sub Category IDs the member is tagged with (multiple allowed; simpler than the join table)

• rel_services rows (Member ↔ Sub Category links) -> used when you need per-link metadata like avg_price, specialty, num_completed. Optional; most sites use just the CSV field.

Sub-sub-categories: createSubCategory with master_id=<parent service_id> creates a Sub Category nested under another Sub Category (a "sub-sub"). master_id=0 (default) means the Sub Category sits directly under a Top Category (the profession_id).

There is NO createProfession or createService tool in this MCP — those are BD's internal table names. Use createTopCategory / createSubCategory instead (BD's table-name → tool-name mapping is documented in Rule: Table to endpoint).

Create a service - Create a new SUB-level member category under an existing Top Category. Writes live data.

A Sub Category is level 2 of the 3-tier member classification. It MUST have a parent Top Category (via profession_id). It may optionally sit under another Sub Category (for sub-sub-category nesting, via master_id). Backed by BD's list_services table.

Use when: explicitly adding a sub-category BEFORE assigning members to it. If creating/updating a user who needs a sub-category that doesn't exist yet, on createUser just include the name in services - BD auto-creates it. On updateUser, pass create_new_categories=1 to allow inline creation. For sub-sub nesting pass master_id=<parent service_id>; otherwise set master_id=0 for direct-under-Top.

Required: name, profession_id.

Pre-check before create: BD does NOT enforce uniqueness on filename (URL slug) or name - but uniqueness IS scoped per-parent (two sub-cats with the same filename under different profession_id is fine; same filename under the SAME profession_id is not). Do a server-side filter-find: listSubCategories property=filename property_value=<proposed> property_operator==, then filter results by the intended profession_id. Zero rows under that parent = slug free; >=1 row = taken (URL collision - wrong sub-cat page resolves). Do NOT paginate unfiltered lists - filtered lookup is one tiny response. If taken: reuse via updateSubCategory, OR ask the user, OR pick an alternate filename and re-check. Wrapper safety net: on a missed pre-check, the wrapper auto-suffixes filename on collision (-1...-20) and surfaces the suffix in the response. Pre-checking still preferred — auto-suffix surprises the caller in URL-sensitive workflows.

Parameter guidance:

• name - human-readable (e.g. "Sushi")

• profession_id - the parent Top Category's ID (from listTopCategories or createTopCategory)

• master_id - for SUB-SUB-CATEGORY nesting, pass the parent Sub Category's ID; default 0 means "directly under the Top Category"

• filename - URL-slug form; desc, keywords, sort_order, lead_price, image - all optional

See also: updateSubCategory (modify), listSubCategories (list), createTopCategory (create parent).

Writes live data: changes are immediately visible on the public site.

Returns: { status: "success", message: {...createdRecord} } including service_id. Use that to assign members via updateUser.services (CSV) or createMemberSubCategoryLink.

How a member gets classified on their public profile:

• users_data.profession_id -> points at a single Top Category (the member's primary classification; shown in URL slug)

• users_data.services -> CSV of Sub Category IDs the member is tagged with (multiple allowed; simpler than the join table)

• rel_services rows (Member ↔ Sub Category links) -> used when you need per-link metadata like avg_price, specialty, num_completed. Optional; most sites use just the CSV field.

Sub-sub-categories: createSubCategory with master_id=<parent service_id> creates a Sub Category nested under another Sub Category (a "sub-sub"). master_id=0 (default) means the Sub Category sits directly under a Top Category (the profession_id).

There is NO createProfession or createService tool in this MCP — those are BD's internal table names. Use createTopCategory / createSubCategory instead (BD's table-name → tool-name mapping is documented in Rule: Table to endpoint).

Update a service - Update an existing SUB-level member category by service_id. Fields omitted are untouched. Writes live data.

Use when: renaming, re-parenting (change profession_id to move under a different Top, or master_id to re-nest as sub-sub), or adjusting lead_price for per-service lead pricing.

Required: service_id.

Filename rename caveat: if the existing filename has a seo_type=profile_search_results web page bound to it, renaming this category orphans that page. The wrapper rejects renames that would orphan a bound page — rename or delete the bound page first, then rename the category.

Parameter notes:

• Change profession_id to move this Sub Category to a different parent Top Category

• Change master_id to re-nest as a sub-sub-category (non-zero) or flatten to direct-under-Top (0)

See also: createSubCategory (add new), deleteSubCategory (remove).

Returns: { status: "success", message: {...updatedRecord} }.

How a member gets classified on their public profile:

• users_data.profession_id -> points at a single Top Category (the member's primary classification; shown in URL slug)

• users_data.services -> CSV of Sub Category IDs the member is tagged with (multiple allowed; simpler than the join table)

• rel_services rows (Member ↔ Sub Category links) -> used when you need per-link metadata like avg_price, specialty, num_completed. Optional; most sites use just the CSV field.

Sub-sub-categories: createSubCategory with master_id=<parent service_id> creates a Sub Category nested under another Sub Category (a "sub-sub"). master_id=0 (default) means the Sub Category sits directly under a Top Category (the profession_id).

There is NO createProfession or createService tool in this MCP — those are BD's internal table names. Use createTopCategory / createSubCategory instead (BD's table-name → tool-name mapping is documented in Rule: Table to endpoint).

Delete a service - Permanently delete a SUB-level member category by service_id. Destructive - cannot be undone via API.

Use when: removing an unused sub-category. Any member with this service_id in their users_data.services CSV or in rel_services rows becomes orphaned - clean those up first.

Required: service_id.

Destructive: confirm intent. Members whose users_data.services CSV contains this ID will have an orphan reference. Any Member ↔ Sub Category links (rel_services) pointing at this service_id also become orphaned.

Bound-page caveat: if this category's filename has a seo_type=profile_search_results web page bound to it, deleting the category orphans that page (it'll render empty — no category to query). The wrapper rejects deletes that would orphan a bound page — delete or repurpose the bound page first.

See also: updateSubCategory (modify without removing).

Returns: { status: "success", message: "list_services record was deleted" }.

How a member gets classified on their public profile:

• users_data.profession_id -> points at a single Top Category (the member's primary classification; shown in URL slug)

• users_data.services -> CSV of Sub Category IDs the member is tagged with (multiple allowed; simpler than the join table)

• rel_services rows (Member ↔ Sub Category links) -> used when you need per-link metadata like avg_price, specialty, num_completed. Optional; most sites use just the CSV field.

Sub-sub-categories: createSubCategory with master_id=<parent service_id> creates a Sub Category nested under another Sub Category (a "sub-sub"). master_id=0 (default) means the Sub Category sits directly under a Top Category (the profession_id).

There is NO createProfession or createService tool in this MCP — those are BD's internal table names. Use createTopCategory / createSubCategory instead (BD's table-name → tool-name mapping is documented in Rule: Table to endpoint).