Chris is right, you will want to utilize a combination of Data Extensions and Triggered Sends.
On a high level, this is what you will want to do:
- Create a Data Extension from the Triggered Send template within the ExactTarget UI. Add any additional fields in this Data Extension that you will use in your template (for example, the
CustomHTML1
field)
- Set up a Triggered Send Definition within the UI as well. Choose the appropriate Email that you will be sending and select the Data Extension from step 1. Note: ExactTarget uses the term "Email" the same way that most people use "Email Template". An Email can contain Personalization Strings (Merge Fields).
- Be sure to start your Triggered Send Definition.
- Using the API, you can now send an email using your Triggered Send Definition.
In order to pass in the custom data (e.g. CustomHTML1
), you will want to add that name/value pair as a Subscriber attribute in the API call:
ETServiceClient.ETClient.Attribute attr = new ETServiceClient.ETClient.Attribute();
attr.Name = "CustomHTML1";
attr.Value = "Your custom merge field value";
subscriber.Attributes = new ETServiceClient.ETClient.Attribute[] { attr };
The above code should be added in to to the linked code sample as appropriate, it is there only to provide information specific to setting up the custom attribute.
As far as I know, there aren't any single references that spell out this process, however I have found it to be the most effective.
(Also of note, all of the API articles have recently been moved to code.exacttarget.com, so the wiki is going to be somewhat limited use in this situation)
Good luck!
EDIT: I wanted to also clarify that any steps above that call for configuration via the UI can also be done through the API. However, since they are one-time configuration elements, it is typically easier to just log in once, set it up, and focus API development efforts on the actual email sends.
EDIT: For the sake of completeness, it should be noted that it is not necessary to use Data Extensions for this purpose. It is technically possible to have an attribute on the subscriber which serves the same purpose and, if there are situations where Data Extensions won't work, this may be the better option.
I would recommend the DE route if at all possible in this case because it physically separates send-specific data from the subscriber itself. That way, information that may only be relevant for the specific send is not "permanently" stored on the Subscriber.