An integration can create, replace, update, or delete a member’s resume through the Careers API with a signed-in staff or service session. This reference explains how full replacement works for every save, when staff and service callers can use partial updates, how staff notes and custom field values behave, and how to run several resume changes in one request.
Create, Replace, or Delete Any Contact's Resume
With a staff or service session, you can add, replace, or delete a resume for any contact. The usual resume schema rules still apply, so Rhythm refuses a resume for a missing contact or a contact with no name. Unlike the Portal, this API path does not check whether the caller is tied to the resume’s contact, so a staff or service caller can manage resumes for any contact, including moving a resume document from one save to the next.
Change One or Two Fields with a Partial Update
Staff and service callers can send a partial update when they only need to change one or two fields, instead of resending the entire resume. The resume must already exist, and the updated resume still has to pass its schema rules. For example, Rhythm refuses a partial update that removes the resume’s name. Even when you update one field, Rhythm refreshes the contact details that the resume copies from CRM.
Warning
Portal users cannot use partial updates. A resume saved from the Portal is always replaced in full through the ordinary save path. If you need to change only one or two fields for a member, make the change as a staff or service caller.
Staff Notes and Custom Field Values
You can use the API to keep a free-text staff note and your Rhythm account’s custom field values on a resume. There is no Console screen to view or edit either one. The note has no length limit, and Rhythm returns both the note and the custom field values to anyone who can already read that resume, whether they are staff or a Portal user.
Run Several Resume Changes in One Request
A staff or service caller can send several resume operations in one batch request instead of making one call for each change. Each operation follows the same rules as the matching single-request operation. If one operation fails, Rhythm reports that failure for that operation only and does not fail the rest of the batch. Portal users cannot use this batch operation.