I would imagine something like...

$client->api('contact')->update($id, $contactData);

Which should map to...

PUT /data/contact/{id}

Problem/motivation

We live in a multi-tenant world... We shouldn't assume Pod1 if no base URL is provided. In fact, we should require base URL.

Proposed resolution

Require base URL in the authentication method.

This is a breaking change, so we should wait for 1.0.x.

I would imagine something like...

$client->api('contact')->create($contact_data);

Don't know that we need any validation, for now.

Problem / motivation

In Fall 2015, Oracle announced that it had changed the application URLs for Eloqua Pod 01 and Pod 02 to align with all other Eloqua pods.

Effective this coming Fall (2016), Eloqua will not be renewing the old certificates for secure.eloqua.com (for Pod 1) and www.02.secure.eloqua.com for (Pod 2), and, as such, clients must ensure they’re pointing to the newer, updated, application URLs before they expire. Failure to do so before the certification expiration dates will result in any calls to the old URLs failing.

Certificate Expiration Dates:
Pod 1 - Friday, November 18, 2016 for secure.eloqua.com
Pod 2 - Sunday, December 11, 2016 for www02.secure.eloqua.com

After the expiration dates, any calls (API calls, redirects, etc) to the old URLs will not work.

Proposed resolution

We should update all defaults referencing the old POD urls to ensure uninterrupted operation. This includes the REST API as well as the BULK API. For backwards compatibility, we should default to pod1. In a major version bump, we can consider requiring a specific base URL.

Via: http://secure.eloqua.com/api/docs/Static/Rest/2.0/doc.htm

POST/data/contacts/list/{id}/export
GET/data/contacts/list/{id}?depth={depth}&count={count}&page={page}&search={search}&orderBy={orderBy}&lastUpdatedAt={lastUpdatedAt}&viewId={viewId}

Suggested goal implementation / usage:

// GET /data/contacts/segment/{id}
$client->api('contact')->segments($segment_id)->search($search, $options);

// GET /data/contacts/segment/{id}/included
$client->api('contact')->segments($segment_id)->searchIncluded($search, $options);

// GET /data/contacts/segment/{id}/excluded
$client->api('contact')->segments($segment_id)->searchExcluded($search, $options);

// POST /data/contacts/segment/{id}/export
$client->api('contact')->segments($segment_id)->export($data);

See: http://secure.eloqua.com/api/docs/Static/Rest/2.0/doc.htm

Problem / motivation

We'd like the ability to search for, get details on, create, update, and delete dynamic content.

Proposed resolution

We should add support for dynamic content, as well as generic content sections. Potentially:

// Dynamic content.
$client->api('dynamicContent')->search($query, ['depth' => 'complete']);
$client->api('dynamicContent')->show($id);
$client->api('dynamicContent')->create($content);
$client->api('dynamicContent')->update($id, $content);
$client->api('dynamicContent')->delete($id);

// Content sections.
$client->api('contentSection')->search($query, ['depth' => 'complete']);
$client->api('contentSection')->show($id);
$client->api('contentSection')->create($content);
$client->api('contentSection')->update($id, $content);
$client->api('contentSection')->delete($id);

Details

• Content sections /api/REST/2.0/assets/contentSection[s | /[id]], documented [here].
• Dynamic content /api/REST/2.0/assets/dynamicContent[s | /[id]], which is undocumented.

Already implemented:

// GET /data/contact/view/{id}/contacts
$client->api('contact')->views($view_id)->search('*');
// GET /data/contact/view/{id}/contact/{contactId}
$client->api('contact')->views($view_id)->show($contact_id);

To be implemented:

GET /data/contact/view/{id}/contacts/campaign/element/{elementId}
GET /data/contact/view/{id}/contacts/filter/{filterId}
GET /data/contact/view/{id}/contacts/list/{listId}
GET /data/contact/view/{id}/contacts/segment/{segmentId}/excluded
GET /data/contact/view/{id}/contacts/segment/{segmentId}/included
GET /data/contact/view/{id}/contacts/segment/{segmentId}

See: http://secure.eloqua.com/api/docs/Static/Rest/2.0/doc.htm

The extra validation on Email::create() is nice, but the method's signature does not match that of CreateableInterface::create().

We should fix this, but we'll have to wait for 1.0.x, since this has been out in the wild for awhile.

I'm using the bulk API to insert a new contact record when a visitor fills out a contact form on my clients website. This is working great. However, I cannot seem to figure out how I could add this contact to an existing "segment" in eloquoa after being added to the system.

Is there a way to do this via the API and specifically, using this library?

As per the API Docs and this thread:
https://community.oracle.com/community/topliners/code-it/blog/2012/11/30/using-the-eloqua-api--determining-endpoint-urls-logineloquacom#comment-14533

The endpoint URL is different based on your account and where your data is hosted.

This library requires you to manually enter that URL, however the docs provide a way to use the api to find out what endpoint URL to use (see link).

Is this not implemented? How am I supposed to verify I'm using the correct endpoint URL for my data?

Suggested goal implementation / usage:

// GET /data/contacts/campaign/element/{id}
$client->api('contact')->campaigns($campaign_id)->search($search, $options);

// POST /data/contacts/campaign/element/{id}
$client->api('contact')->campaigns($campaign_id)->create($data);

// DELETE /data/contacts/campaign/element/{id}
$client->api('contact')->campaigns($campaign_id)->remove();

// POST /data/contacts/campaign/element/{id}/export
$client->api('contact')->campaigns($campaign_id)->export($data);

See: http://secure.eloqua.com/api/docs/Static/Rest/2.0/doc.htm

I'm trying to use this library to insert contacts from a customers contact form on their website. I'm following the example found here (importing contacts into Eloqua):
https://github.com/tableau-mkt/elomentary/blob/master/doc/customObjects/bulk.md

When I run my code, I get the following exception:

Fatal error: Uncaught Eloqua\Exception\RuntimeException: Client error response [status code] 401 [reason phrase] You are not authorized to make this request. [url] https://secure.p03.eloqua.com/API/bulk/2.0/contacts/imports in C:\Projects\SublymeCommerce\sublyme-lib\sublyme\vendor\tableau-mkt\elomentary\src\HttpClient\HttpClient.php on line 131

Do we need to use OAuth2 for this or do I just have something set wrong for my account?

I would imagine something like...

$client->api('contact')->delete($id);

Which should map to...

DELETE /data/contact/{id}

Via: http://secure.eloqua.com/api/docs/Static/Rest/2.0/doc.htm

POST/data/contacts/filter/{id}/export
GET/data/contacts/filter/{id}?depth={depth}&count={count}&page={page}&search={search}&orderBy={orderBy}&lastUpdatedAt={lastUpdatedAt}&viewId={viewId}

Hi,
Quick query to check if this project is still actively maintained?

Currently, if an exception is thrown a null error message is passed through the exceptions.

It would be great if the errors were passed down through the chain.

Is this project still under active maintenance?
I would like to have some additional functionality and am wondering if this is worth investing time into? From my research, this hasn't really had anything done to it since Jun 2017.
Thanks.

Problem / Motivation

The composer.json used by elomentary still refers to the now EOL Guzzle 3.x packagist name: guzzle/guzzle
https://github.com/guzzle/guzzle#version-guidance

We should look at updating to the maintained / latest version.

A few things:

1. We should update the Contact::subscriptions method to pass in options (like count, page, search, orderBy, lastUpdatedAt).
2. Add support for getting an individual e-mail group subscription
   • Signature: Contact::subscription($contact_id, $group_id)
   • Request: GET /data/contact/{contactId}/email/group/{groupId}/subscription
3. Add support for updating an individual e-mail group subscription
   • Signature: Contact::updateSubscription($contact_id, $group_id, $subscription_data)
   • Request: PUT /data/contact/{contactId}/email/group/{groupId}/subscription

And maybe we might break off contact-specific subscription stuff into its own class? Like...

$client->api('contacts')->subscriptions($contact_id)->show($group_id);
$client->api('contacts')->subscriptions($contact_id)->update($group_id, $subscription_data);

If we do, obviously the signatures would change, above.